← All guides
Workflow / Any creative tool

Keep editable sources and game exports easy to find

Set up a small, traceable asset handoff so you know which source produced the file in your game.

Beginner About 20 min practiceFree guide

First Play Studios · Edition 1 · Updated November 14, 2026

WHAT YOU’LL MAKE OR LEARN

A small asset folder with a source, an export, and enough notes to repeat the handoff.

Before you start
  • One practice asset you created
  • Its editable source and a delivery export
  • A plain-text editor
In this guide
01

Give each file a clear purpose

An editable source preserves the working structure of an asset: a Blender scene, Krita layers, or an Audacity project. A delivery export is the file consumed elsewhere, such as a .glb, .png, or .wav. Both matter. A game-ready image may look correct but cannot replace the convenience of its named editing layers.

For this exercise, use a small folder named signpost-study with source, exports, and notes subfolders. This is an example convention, not a universal engine structure. If your engine tracks assets with metadata or import rules, keep its existing structure and create this practice folder separately.

02

Write down the handoff

Choose a stable asset name such as signpost, then a revision label such as v01. Keep the source and export names related: signpost_v01.blend and signpost_v01.glb. A revision is useful only when you know what changed; final_final_reallyfinal does not describe that.

In notes/export-record.txt, record the source filename, creative-tool version, export filename, intended dimensions or duration, and one visible check. Add the destination project or test scene if you used one. For an asset you did not create, keep its original source link and accompanying permission or license information with your records; an attribution note alone does not establish permission.

03

Prove you can find and reproduce it

Close the working document, then reopen the source using its folder path. Check that external images or other dependencies are still available. Blender files can reference external resources; moving only the .blend can leave those references unresolved. Move or copy practice dependencies together and verify the result before cleaning anything up.

Make one small change and save a v02 source and export. Add a line explaining the change. Ask whether you could identify the version inside a game without guessing. A clear filename and export record reduce time spent editing an old source or testing a stale delivery file.

TRY IT YOURSELF

A handoff your future self can repeat

  1. Create the three practice subfolders without moving files inside a working engine project.
  2. Copy your editable source into source and its delivery file into exports.
  3. Write an export record with the two filenames, tool version, intended size or duration, and a check result.
  4. Reopen the source from that location and confirm its dependencies are available.
  5. Create a small v02 revision and record what changed; retain v01 for comparison.

Check your result.

  • You can point to the editable source and the delivery file without opening several mystery versions.
  • The source reopens with its expected resources.
  • Your notes say which export was tested and where.
Guest progress stays in this browser. This records your own practice; it does not automatically test your project.

Common mistakes to watch for.

  • Renaming engine-managed assets outside the engine without understanding its metadata rules.
  • Keeping a new export beside an old source without recording their relationship.
  • Deleting earlier versions before checking the replacement.
YOUR PROJECT. YOUR OWN CHATGPT.

Keep the conversation useful.

Help me design a small asset handoff for [tool and version] into [engine and version]. I have [source types] and [export types]. Propose a simple naming and record format that fits this existing project structure: [structure]. Do not suggest moving engine-managed files until you explain their metadata requirements.

Sources & version notes.

The folder convention is an original exercise. File-format examples draw on Blender 4.5, Krita 5.x, and Audacity 3.x documentation; follow your engine’s own asset-management rules.

Further reading from the original documentation:

Practice times are estimates. Software-specific exercises are documentation-based unless their version note says otherwise.
MAKE IT A CONVERSATION

A question or a small win?

Tell the workshop what happened when you tried this guide. Ask for a useful next step, or share something you got working.

See discussions about this guide We’ll include the guide link in your draft. Sign in to post, then add your own question or progress before sharing.
KEEP GOING

One idea leads to another.

Find a bug without changing everythingFind a performance problem before fixing itMake your first local Git checkpointExplore a learning path