Game development planning
Game Art Asset Handoff Checklist for Small Indie Teams
Use this game art asset handoff checklist to verify source files, export settings, reimport safety, and playable proof before your indie team accepts an asset.
An art asset is ready for handoff when someone other than its creator can import it, update it, and see it work in the game. For a small indie team, use two acceptance gates: the artist verifies the source and export; the integrator verifies the engine result and build. A polished render or successful first import proves neither.
Agree on an asset contract before exporting
Before producing a batch, write down what the game needs from one representative asset. This prevents incompatible assumptions from spreading across ten variations.
Keep the contract explicit:
- Asset ID and use: a stable name and the player-facing situation where it appears.
- Editable source and delivery: where the source project lives, expected exported files, and who can reproduce the export.
- Transform: scale, orientation, pivot, and any animation or socket naming rules.
- Materials: texture channels, material slot names, and whether assignments happen in the source tool or engine.
- Runtime constraints: collision, LODs, target platform, and project-specific performance limits.
- Review ownership: who prepares, integrates, and tests the asset in a playable scene.
Unity's model import settings cover scale, axis conversion, and hierarchy preservation. Unreal's FBX static mesh pipeline documents material slot ordering, collision naming, and import limitations. Export defaults can work for one team and break another's prefabs.
Don't impose a universal triangle count or texture size. Agree on a budget for the camera distance, target hardware, and asset type. A background rock and interactive hero prop need different checks.
When another task cannot start without the asset, record a specific art-to-code dependency, not “waiting on art.”
Run two acceptance gates, including reimport
Gate A — artist delivery. The artist checks that the source opens, dependencies are present, the export is reproducible, and pivot, orientation, and material slots match the contract. Record the source revision and export filename; avoid folders of indistinguishable “final” files.
Gate B — integration. The receiving teammate imports into the current project and checks:
- The expected size, position, orientation, and materials appear in the target scene.
- Collision, animation, or attachment points work when required.
- The player route displays the asset correctly under game lighting and camera.
- Re-exporting and reimporting a controlled change preserves references and engine-side work.
- The revision and tested build or scene are recorded.
The fourth check is often skipped. Godot's advanced import documentation explains that renaming a source material can break its association with an extracted material on reimport. Unreal's FBX documentation also warns that some imported maps are not connected automatically. First-import success isn't proof that updates are safe.
For binary source art kept in Git, Git LFS can track large files without placing their full contents in ordinary Git history. It doesn't prove another teammate can open the source. For shared storage instead, record the authoritative file location and version.
Copy this handoff card into your next asset task
Hypothetical example: a three-person puzzle-game team needs an iron gate that swings open when the player solves a switch puzzle. The artist exports the model; the programmer must animate it from the hinge and keep collision aligned.
- Asset / use:
gate_iron_01— interactive courtyard gate. - Source / export:
art/gates/gate_iron_01.blend→game/gate_iron_01.glb, with textures. - Contract: 2.4 m high; pivot at hinge; stable material names; closed gate blocks passage; open gate permits passage.
- Artist proof: source opens, export reproduced, hinge and material slots checked.
- Integrator proof: rotation around hinge, collision follows the intended state, materials display, and route works in the milestone build.
- Owners / evidence: artist prepares; programmer integrates; reviewer records build ID, pass/fail, and issues.
Suppose the first export has its origin at the model's center. The mesh looks fine in a viewer, but swings around its middle. Gate A fails: the artist corrects the pivot before acceptance.
On the next export, the artist renames a material. If an engine-side assignment breaks, Gate B fails until the association and update path work. Neither issue should silently become the programmer's “polish later” task.
The record lets the team reject a delivery without debating whether the art looks good.
Accept the working asset, not just the delivered file
Use three review decisions:
- ACCEPT: contract, relevant import checks, and playable proof pass. The next discipline can use it.
- RETURN: the artist corrects a source or export issue; name the failed check and required result.
- SPLIT AND TRACK: a nonessential improvement is deferred to a separate ticket with an owner and acceptance check.
Don't defer a broken pivot, missing reference, or collision required by the current player route. Conversely, temporary placeholders need a lighter contract than final reusable assets; optimizing every prototype prop wastes time. Your team Definition of Done can define the relevant gate for each asset class.
Pick one asset blocking your next playable build. Write its contract, ask someone else to perform the import and reimport check, then record the decision. If you use PlayablePlan, keep the handoff task, owner, blocker, and milestone together instead of burying the result in chat.