Every game project eventually drowns in files: 400 icons, 12 tilesets, 8 versions of each, and a folder called "final_final_v3". The difference between a team that ships and a team that drowns is often nothing more than how they organize assets. This guide gives you a naming and folder system that pays for itself in the first week.
The cost of disorganization
Disorganized assets cost time in three ways: searching (where is the sword icon?), duplicating (I re-generated what already exists?), and breaking (I overwrote the good version with the bad one?). Each is a tax on every asset interaction, forever. A naming and folder convention is the cheapest infrastructure you will ever build.
The folder structure: type, then category, then object
A structure that scales from 20 assets to 2,000:
assets/ ├── icons/ │ ├── weapons/ │ ├── potions/ │ ├── gems/ │ ├── magic/ │ └── ui/ # frames, badges, cursor icons ├── tiles/ │ ├── terrain/ │ └── props/ ├── ui/ │ ├── panels/ │ └── buttons/ ├── characters/ ├── fonts/ └── _source/ # masters and editable files, never shipped
The rule: type first (icons vs tiles vs UI), then category (weapons vs potions), then object. This ordering means related assets sit together and the tree stays navigable at every depth. The `_source` folder holds masters — what you ship lives in the other folders.
Naming: snake_case, type prefix, size suffix
A naming convention prevents the two worst sins: duplicate names and version soup. The format that works:
<category>_<object>_<variant>_<size>.<ext> weapon_sword_fire_512.png potion_health_small_128.png gem_ruby_epic_256.png ui_frame_circle_64.png
Rules that make this work:
- snake_case only (no spaces, no CamelCase, no capitals)
- Category prefix so files sort into groups
- Variant suffix for versions that coexist (fire vs ice, epic vs common)
- Size suffix when the same asset exists at multiple sizes
- No dates, no "final", no "new", no "v2" — versioning belongs in source control
If a file needs a date or a version number in its name, you are not using version control properly.
Versioning: git or nothing
Asset versioning has one professional answer: version control. Games increasingly store binary assets in Git (or Git LFS for large files), because it solves overwrite, history and collaboration at once.
- Commit the master assets, not just the build output
- Name branches by feature, not by asset
- Tag releases so "the version that worked" is one command away
- Never keep an "old" folder — that is what history is for
If you work solo without version control, the minimum is: never overwrite a master — save a new file with a variant suffix and delete the old one only when you are sure.
Masters vs exports: keep them separate
The single most common asset disaster is editing an export and losing the source. The rule:
- Masters live in _source (generator output, layered files, original drawings)
- Exports live in the ship folders (scaled, compressed, format-converted)
- Never edit an export and call it a master
- Regenerate exports from masters with a script when possible
When you use a generator, the seed and settings are the master. Save them — a small JSON per icon set (element, style, palette, frame, seed) lets you regenerate anything forever.
Metadata: the spec travels with the art
A folder of PNGs is half the asset; the other half is the spec. Keep it minimal and local:
- One STYLE.md per asset type (frame, palette logic, stroke weight, light direction)
- One MANIFEST.json or README.md listing the set and its sources
- License files: a LICENSE.txt copied from every source (see the licensing guide)
The style sheet is what makes future assets match. The manifest is what makes handoff possible. The license file is what keeps you out of court. All three are small, and all three are non-negotiable in a professional pipeline.
The one-hour cleanup routine
If your asset folder is already chaos, fix it in one focused hour:
- Create the type/category/object structure
- Move every file in (keep file names for now — renames can come later)
- Identify masters and move them to _source
- Delete obvious duplicates and "old" files you can prove are superseded
- Write the STYLE.md from your generator settings
- Commit to version control
The payoff is immediate and compounding: every search becomes a folder browse, every "which version?" becomes a git log, and every new asset has a home. Organization is not bookkeeping — it is the difference between a library you use and a landfill you dig through.
Naming tools that do the work for you
If you manage assets across several projects, a few small tools make the convention stick without discipline. A generator that exports with your naming scheme built in (category_object_variant_size) removes the rename step entirely; a bulk renamer handles legacy folders in one pass; and a simple index script that walks your tree and lists orphaned or duplicate files catches the drift before it becomes a problem. None of these need to be fancy — a 30-line script beats a month of hand-renaming.
The same tools pay off when you onboard a collaborator. A folder with a README that says "assets are organized by type, named snake_case with size suffixes, masters live in _source" lets a new team member find anything in minutes. The convention is not for you — you already know where things are. It is for the future version of you with a worse memory, and for the teammate who will quietly resent a folder full of final_v2_final.
And when a project ends, resist the urge to leave everything in place and walk away. Ten minutes of tidying — archiving obsolete sets, moving prototypes out, updating the manifest — turns a finished project into a reusable asset library for the next one. Games reuse more art than developers admit; the ones who organize are the ones who can.