8 min read

Organizing Concept Art and References for a Story World

A story world collects pictures the way a kitchen drawer collects rubber bands. A screenshot of a harbor for chapter three, a sketch of the villain's coat, a texture you liked, a track that sounds like the desert city. Six months later you need the coat and find four versions, none labeled, one of them a photo of someone else's painting you saved without the source.

This post is a system for keeping that library usable: how to name and tag files, link them to the characters and places they describe, track versions, keep sources for images you did not make, handle 3D and audio, and keep the whole thing from rotting with a short weekly routine.

Why references go stale

References stop being useful for predictable reasons:

  • No context. A file called IMG_4471.jpg meant something the day you saved it. Now nobody knows which character it is for or what part of it mattered.
  • The world moved on. You changed the villain's coat from leather to wool in draft two, but the old leather reference is still the first thing anyone sees.
  • Duplicates. The same image saved three times under three names, each with different notes.
  • Lost origins. No record of where an image came from, so you cannot credit it, check its license, or find a higher-resolution copy.
  • Buried in chat. Half the references live in message threads with collaborators and never make it into the project.

Every habit below targets one of these.

Folders vs tags

Folders put each file in exactly one place. They are easy to understand and they work with any tool. Their weakness is that a file often belongs in two places: a sketch of Mara on the harbor wall is both a character reference and a location reference.

Tags let a file belong to as many groups as it needs. Their weakness is drift: "harbour," "harbor," and "docks" become three tags for one idea.

The practical answer for most projects is a shallow folder structure plus a small controlled tag list:

  • Folders by type of asset: characters, locations, props, creatures, moodboards, audio, 3d, video.
  • Tags for everything else: who is in it, which place, which chapter or episode, status (approved, explore, rejected), and source (original, external-ref).

Keep the tag list written down in one note. When you want a new tag, add it to the list first. That single rule prevents most drift.

Naming conventions

A good file name lets you know what a file is without opening it, and it sorts sensibly. One workable pattern:

[project]_[subject]_[type]_[descriptor]_v[##]

Examples, using an invented project called Saltgate:

SG_mara_modelsheet_coat-wool_v03.png
SG_harbor-wall_keyframe_dusk_v01.jpg
SG_lantern_prop_turnaround_v02.png
SG_desert-city_mood_heat-haze_v01.jpg
SG_market_ambience_morning_v01.wav

Rules that make the pattern hold up:

  • Lowercase except the project code, and hyphens inside a field, underscores between fields.
  • No spaces, no special characters, no dates in the middle (put dates in metadata or notes if you need them).
  • Subject names match the names used in your manuscript and character files exactly. If the character is "Mara Venn," pick mara and never write venn or mv elsewhere.
  • Two-digit version numbers so v10 sorts after v09.

Linking art to characters and locations

A reference that is not attached to anything is just a file. The useful move is to link each image to the entity it describes: the character, the location, the item, the faction. Then when you open Mara's character page, her approved model sheet is right there, and when you open the harbor, you see the dusk keyframe and the mood board.

Two habits help:

  1. Mark one image as the canonical reference for each major entity. Everyone (including future you) uses that one first. Explorations stay linked but clearly secondary.
  2. Write one line of intent beside each linked image. "Coat silhouette only, ignore the colors" saves a collaborator from copying the wrong thing.

This matters even more in production work. A storyboard artist pulling references for a shot list needs to know which version is current; there is more on that handoff in shot lists and storyboards for indie filmmakers.

Versioning: final is never final

Never name anything final. You will end up with final, final2, and final_REAL. Use version numbers and a status tag instead.

  • Increment the version whenever the design changes in a way someone might want to compare: v01, v02, v03.
  • Keep old versions, but tag them superseded so they drop out of the default view.
  • When a version is approved, tag it approved. If a later change is approved, move the tag. There is only ever one approved version per asset.
  • Note what changed in one line: "v03: coat switched to wool, collar raised."

This gives you a trail when someone asks why the coat changed, and it lets you roll back when the new version turns out worse.

Mood boards, model sheets and turnarounds

These three get mixed up, and they serve different jobs:

  • Mood boards collect tone: palette, light, texture, feeling. They are allowed to be loose and borrowed. Nobody should draw directly from a mood board; it tells you how a place feels, not what it looks like.
  • Model sheets define a design: a character or prop shown clearly, often with expressions, proportions and key details called out. They are the source of truth for consistency.
  • Turnarounds show the same design from several angles (front, three-quarter, side, back) at consistent scale. They matter most for comics, animation and 3D, where the subject will be drawn or built from every side.

Store them in different places or tag them distinctly. A mood board mistaken for a model sheet is how a character's costume ends up changing between chapters.

Licensing and attribution for references you did not make

Reference images you found online are references, not permission. Being able to save an image does not mean you can reuse it in your published work, your pitch deck, or your cover.

Practical rules:

  • Keep the source. For every external image, record where it came from and who made it, in a note attached to the file or in the file's description. If you cannot find the source again, treat the image as unusable for anything public.
  • Tag it external-ref so it can never be confused with original art.
  • Use it to learn, then make your own. Study the light, the shape language, the clothing construction. Then draw or commission original work.
  • Do not trace or paste external references into final art. If you need a specific photo in the final product, get a license or permission, and keep a copy of it with the file.
  • Check the terms for stock libraries and asset stores. Licenses vary, and some do not allow use in commercial projects or require credit.

This is general practice, not legal advice. If a project is going to be published or sold, read the actual license terms or ask someone qualified.

3D models and audio as references

Not every reference is a flat image.

3D models are excellent for turnarounds and consistent lighting: block out a building or a vehicle once and you can pose a camera anywhere. For game projects they may become actual assets, so record which ones are placeholders and which are production. If your levels or quests depend on specific locations, link the model to the location so level designers and writers see the same thing (see quest design for narrative designers for how location and quest beats connect).

Audio references (ambience, music sketches, a voice that sounds like a character) shape tone the way mood boards do. Name them with the same pattern, link them to the place or character, and note whether they are original or external, with the same sourcing rules as images.

File size hygiene

Large files are where libraries get slow and storage fills up.

  • Video: keep a compressed review copy for reference and store the full-quality master once, somewhere backed up. Do not upload five slightly different renders.
  • 3D: export a lightweight format for viewing and keep the working source file with its textures together, so nothing breaks when moved.
  • Images: a reference rarely needs to be print resolution. Keep the original when it is your own art; downscale external references to what you need to see.
  • Audio: keep lossless masters for original recordings, compressed copies for references.
  • Prune rejected explorations periodically. Keep a few for history, archive the rest outside the project.

A weekly maintenance routine

Fifteen to thirty minutes once a week keeps everything current:

  1. Inbox sweep. Pull new references out of chats, downloads and your phone into the project.
  2. Rename and tag everything you pulled in, using the naming pattern and the controlled tag list.
  3. Link each new file to its character, location or item.
  4. Check sources. Any external-ref without a recorded source gets one, or gets deleted.
  5. Update approvals. If a design changed this week, move the approved tag and mark the old version superseded.
  6. Check size. Remove duplicates and oversized review copies.
  7. Note what is missing. If a major location still has no canonical reference, add it to your to-do list.

The routine works best right after your weekly writing review, when the changes in the story are fresh. For building out the world those references describe, the worldbuilding guide for fantasy authors covers the writing side.

Organizing references in Aevon

Aevon's asset library keeps concept art, reference images, 3D models, audio, video and documents in one place per project, so references stop living in scattered folders and chat threads. Each user gets 5 GB of storage, and files larger than 25 MB upload through Rapidfile, which is where the file size habits above pay off: compressed review copies and pruned explorations stretch that space further.

The library lives in the same project as your characters, locations, items, lore and maps, so the coat model sheet and the character it belongs to are never in different apps, and everyone working on the project sees the same references. Use your naming pattern and the one-line intent notes so the connection between a file and its entity is obvious. For game projects, Game Studio works with 3D model assets, and in Musical Studio demo audio can be attached to songs. Comic, screenplay and novel projects draw on the same library.

With collaboration roles (owner, editor, viewer) and change approval, the owner can review edits before they land, which helps when several people are adding to the same library. Set up your naming pattern and tag list first, then start moving your references into the asset library one entity at a time.

Further reading