Most indie projects don’t fail because the engine is wrong. They fail because the project becomes hard to work in.
After a few months, you start losing time to things that shouldn’t be hard: hunting for the right material, wondering where a shader variant lives, or re-importing assets because you can’t tell whether you’re touching the “real” one. The fix is rarely a new tool. It’s usually a simple, enforced asset folder taxonomy.
This post is a practical scheme you can apply to Unity or Godot. It’s designed to reduce reference breakage, make “find the thing” searches predictable, and make onboarding another developer (or future-you) less painful.
The problem with ad-hoc folders
Ad-hoc organisation tends to grow in two failure modes:
- Artist-led structure: folders arranged around the creator’s habits (e.g. Sam’s stuff, Textures2). Works until you have to find anything quickly.
- Type-led structure that ignores usage: folders grouped by asset type (Materials, Meshes, Audio) without capturing how they’re intended to be used (UI vs world, player vs enemy, prototype vs shipping).
Both lead to the same outcome: duplicates proliferate and references become brittle.
Principle: organise by intent, not by file type
File type grouping is useful, but intent grouping is what prevents duplicates. You want someone to ask, “Where should this asset go?” and get a confident answer.
A good taxonomy usually includes:
- Scope: what system or feature it belongs to.