How We Work
Our workflow optimises for efficiency, stress-free working, organisation, and transparency. The
whole team should know what is going on and where they fit into it.
Almost every specific rule in Workflows is a consequence of one of the ten below. Learn these
and the rest stops feeling arbitrary.
1. The name decides the folder
There is no lookup table between a file's name and where it lives. The Category token in the name
is the folder name. That is why the folders are Kit and Surface, not Kits and Surfaces.
SM_Prop_Furniture_Table_01 goes in Meshes/Prop/Furniture. Nothing else. If you can't tell where
a file goes, the real problem is its name.
2. Generated things are never hand-edited
Anything under /Exported is produced by a tool. So is Asset Rules (Generated). So are the
tables on half the pages in Workflows.
Editing one of them is worse than it looks. Your work silently disappears on the next
regeneration, after you have already stopped thinking about it.
If a generated thing is wrong, change what generates it.
3. Everything has an owner
Every kit, every scene layer. The owner knows it, maintains it, and confirms changes to it.
This isn't bureaucracy. It answers "who do I ask", which is otherwise the most expensive
question in a studio. If you don't know the owner, that is a question with a fast answer.
4. Lock it, edit it, let it go
Our project files are binary and cannot be merged. Two people editing one .blend means one of them
loses work. So files are locked while you hold them.
The cost is that a lock you forget about blocks someone else. Take the lock, do the work, release it.
Don't hold one overnight because you might come back to it.
5. Never move, rename or delete a Unity asset outside Unity
Not in Explorer. Not in your Git client. Doing it orphans the .meta file and breaks every
reference to that asset.
This is the single most common way a Unity project gets silently broken, and it is tempting
precisely because moving files in Explorer is faster.
6. Number from 01, always
Even when there will only ever be one. SM_Prop_Furniture_Table_01, not ..._Table.
The day there is a second one, nothing has to be renamed. A rename means touching every
reference, every prefab, every scene. Typing two characters now saves you an afternoon later.
7. Nothing is loose at the root
In a scene, everything lives under a section header. In the project, everything lives in the folder
its name dictates.
A root full of loose objects is how a scene becomes unreadable, and it happens one harmless
exception at a time.
8. A conflict on an exported file is re-exported, not merged
If two people conflict on an .fbx, a .png, or anything under /Exported, the answer is to
re-export it from source.
Never resolve it by hand. The result will look plausible and be wrong, which is the worst of
both outcomes.
9. The tools already know if you are wrong
You do not have to memorise the conventions, and nobody expects you to. Three things check your
work and tell you the exact rule you broke, by id, with the fix:
- Workspace Check checks the whole project folder in one pass
- The Blender add-on's Asset Rules panel checks while you are still modelling
- Run Tests in the Bubbly Asset Editor checks authored data
Run them before you commit, not after someone else finds it.
10. Rules change through the team, not in a file
Workflow changes are discussed with the whole team, tested, announced before they happen, and
approved by the studio leads. Rule changes included.
The flip side: a rule that is wrong is worth raising. Several of the conventions in these pages
exist because someone new said "this doesn't make sense" and was right.
Almost everything above traces back to one decision: that a file's name is the only thing carrying its meaning, so the name has to be enough on its own. No database, no tagging system, no metadata sidecar to keep in sync. The cost is that names are strict. The payoff is that a tool, a folder structure, an importer and a person all read the same string and reach the same conclusion.