A commissioned slot is usually described in two halves that are bought from different people. The math model decides what happens. The front end decides what the player sees while it happens. Between them sits a third artefact that neither side quite owns until someone writes it into the brief: the animation source, its export and the contract that lets a static build play it.
The handoff is where commissioned games lose weeks. Not because the animation is bad, but because the client received a file it could not load, an atlas packed for a renderer it does not use, or an animation whose name in the client no longer matches the name in the project after a rename. This article sets out what the brief has to settle about that handoff, file by file, and follows the published Spine and Engine documentation rather than a particular studio’s habit.
What the platform actually receives
Engine games are submitted as static files. There is no server-side rendering step that could re-pack an atlas or transcode an image on the way in, and the approval guidelines are explicit that all images and fonts must be loaded from the Engine content delivery network. Two further rules shape the animation scope: submitted games must use unique audio and visual assets — assets supplied with the web-sdk sample games are not approved for publication — and the game must be free of visual bugs, including broken or missing assets or animations.
Those three requirements decide what the handoff must produce. The build is static, so every skeleton, atlas page and image has to be final before submission. The assets are served from a CDN, so the atlas pages are ordinary image files under the same delivery rules as the rest of the art. And the approval check looks at what the player sees, so a skeleton that loads but renders a missing attachment is a submission defect, not a cosmetic one.
The editor version is the first constraint, not the last
Spine’s own export documentation states the rule plainly: the version of the Spine editor used to export must match the version of the Spine Runtimes, and when the runtimes are updated to a newer version the data must be exported again from the project file. That single sentence generates three obligations for a commissioning brief.
First, the runtime version is pinned somewhere the client and the studio both read, and the studio’s export settings are part of the delivery rather than a local preference. Second, the Spine project files themselves are a deliverable, not a working artefact the studio keeps: without them, a future runtime upgrade cannot be re-exported and the game’s animation becomes frozen at whatever runtime it shipped with. Third, the export dialog’s version field is not a compatibility tool. Spine documents that exporting to an older JSON version is intended only as a last resort to partially recover work, and that data may be lost with warnings shown. A brief that asks a studio to “export for an older runtime” is asking for a partial file, and the failure surfaces at integration.
One export produces one file per skeleton
Spine exports a data file for each skeleton in the project. It is not possible to export a single skeleton from a multi-skeleton project, nor part of a skeleton, nor individual animations. The whole skeleton ships, which makes the skeleton layout a brief decision: a game whose symbols, character and background are separate skeletons needs three exported skeletons and however many atlas pages they pack into, while the same art as one skeleton is one export with many animations inside it.
Neither layout is wrong, and the choice is not primarily aesthetic. Separate skeletons can be attached or detached per screen, which suits a lobby or a feature screen that does not need the reels loaded. A single skeleton shares one atlas and one draw batch for everything that appears together. What the brief should not leave open is which one the client expects, because the answer determines the file count, the atlas layout and how the front end constructs its scene.
The atlas is a production decision, not an export detail
Spine’s texture packer exposes settings that a client cannot fix later in code: maximum page width and height, rectangle versus polygon packing, whitespace stripping, bleed, scale with an optional suffix, and premultiplied alpha. The documentation’s guidance on premultiplied alpha is the reason this belongs in the brief rather than in the export notes — the setting has to match how the images are rendered at runtime. Bleed exists to prevent filtering artefacts when premultiplied alpha is not used, and it does nothing useful when it is.
Two consequences follow. The first is that the client’s blending mode is a handoff input: a studio exporting straight alpha into a client that blends premultiplied textures gets dark fringes on every soft edge, and the defect looks like bad art. The second is scale. Packing at a scale other than 1 with a suffix is how a game gets a lower-density atlas for smaller screens without a second set of source images, and if the client never asks for that suffix, the packed page is shipped but never used.
Repeatability matters as much as the values. Spine can save the current export configuration as a JSON file and load it again, and packing during data export reads a pack.json per folder when the image-folder option is used. A studio that hands over an atlas without the settings file has handed over an output, not a process, and the next re-export after a runtime upgrade becomes an experiment.
The name contract
A front end does not call animation number four. It asks the skeleton for an animation by name, and it binds that name to an event in the math model’s event stream: a scatter anticipation, a reel stop, a win presentation, a mode entry. When Spine’s export omits an attachment — and it will, if the attachment is not exported and keyed in animations, the keys are not exported either — the animation still plays, but it plays without the prop it was built around.
The brief should therefore carry a name table as a deliverable, not a courtesy: skeleton name, animation names, attachment and region names, and the math event each animation is triggered by. The table is what makes integration reviewable. Without it, the first integration meeting is spent comparing spreadsheets of event names against a client constant file, and every mismatch looks like a bug in someone else’s work.
Who delivers which file
The responsibility split is worth writing down because it is uneven across projects and each line has a different owner when something fails:
- The studio delivers the Spine project files, the export settings JSON, the binary or JSON data file per skeleton, the atlas file and its page images, and the name table.
- The client developer delivers the runtime integration: the Spine runtime version pinned in the build, the loader that fetches atlas pages from the CDN, the blending configuration that matches the atlas packing, and the event-to-animation bindings.
- The platform supplies the asset hosting and the review that rejects broken or missing animations, and it does not repack or convert anything for you.
JSON or binary is the studio’s call to justify rather than a default. Spine documents that JSON data is much larger than binary and loads much slower, while binary is unreadable to tools. For a game where the client only ever loads the export, binary is the smaller and faster artefact; JSON earns its size when a pipeline step needs to read or modify the data.
The licence question belongs in the brief
Spine’s Runtimes License Agreement, last updated April 2025, permits integrating the runtimes into software provided that each user of the resulting products obtains their own Spine Editor license, and it requires that redistribution of the products in any form includes the licence and copyright notice. Whether that obligation binds the publisher, the studio, the operator distributing the game or each developer touching the build is a legal question for the parties’ counsel, not something an article can settle.
What the brief can settle is that the question is asked before the build ships: who holds the editor licence used to produce the files, whether the notice is included in the delivered build, and whether a runtime upgrade would change either answer. A licence notice added after submission is a build change, and build changes after approval have their own review path.
The acceptance evidence
Acceptance for the animation handoff is inspectable, and the brief should name the checks rather than the feeling that it looks right on the studio’s machine:
- Every atlas page the build references resolves from the CDN with a 200 response and the expected image type.
- Each skeleton loads from the pinned runtime version without a version-mismatch error, and the build’s runtime version is recorded next to the export version.
- Each animation in the name table plays from its bound event, with all attachments present — no placeholder regions and no silently missing props.
- The packed scale the client requests is the scale that exists in the atlas, and no unused duplicate pages ship.
- The animation set holds its memory and load budget on the target devices, measured against the game’s own performance budget rather than a generic device list.
The Engine front-end acceptance checks cover the rest of the submission surface, and the device performance budget is where the atlas cost actually lands. Where a project needs a formal animation brief for the motion itself — characters, symbols, transitions and their timing — that document is a separate deliverable from the technical handoff described here.
What the brief should record
Before the front end is built, the commissioning brief should fix: the runtime version and who owns the export settings file; whether the delivery is JSON or binary; the skeleton layout and therefore the file count; the atlas page ceiling, packing mode, premultiplied alpha setting and scale suffixes; which atlas pages the client requests and which blending mode it applies; the name table linking animations to math events; the licence holder and where the notice ships; and the acceptance checks each side will run.
None of these are unusual questions for a studio that ships Engine games, and none of them require new tooling. They are expensive only when they are answered in the wrong order — after the atlas has been packed, after the runtime has been upgraded, or after the names have drifted. Settling them in the brief is what makes the handoff a delivery instead of a negotiation.
Frequently asked questions
Does the Spine editor version have to match the runtime version?
Yes. Spine’s export documentation states that the version of the Spine editor used to export must match the version of the Spine Runtimes, and that when the runtimes are updated to a newer version, the data must be exported again from the project file. That is why the project files are a deliverable rather than a studio working file.
Can a studio export one animation from a Spine project?
No. Spine creates a data file for each skeleton in the project, and it is not possible to export only a single skeleton, only part of a skeleton, or individual animations. The whole skeleton is exported, although the export settings allow skeletons, skins and attachments to be excluded by unchecking their Export property.
Why does premultiplied alpha matter in a slot animation handoff?
Spine’s texture packer documentation states that the premultiplied alpha setting should match how the images are rendered at runtime. If the atlas is packed one way and the client blends the other way, soft edges render with dark fringes. The bleed setting, which prevents filtering artefacts when premultiplied alpha is not used, does not substitute for getting the packing and blending to agree.
Who has to hold a Spine Editor licence for a commissioned game?
Spine’s Runtimes License Agreement permits integrating the runtimes provided that each user of the resulting products obtains their own Spine Editor license, and requires that redistribution includes the licence and copyright notice. Which party that binds in a specific commission is a legal question for the parties’ counsel; the brief should record who holds the licence and where the notice ships.
