If you’re not touching the prefab, simply adding it as a child to another prefab (via nesting), then upgrading the prefab that’s nested will automagically upgrade. GUIDs are actually not an issue when upgrading store assets, because the developer should be using the same GUIDs.
1 Like
Wow - That great and useful to know. This completely explains the “why” behind so many folder structures I see.
I don’t think having your own stuff in a folder called Game (or whatever you like) is a redundancy. I did something similar on a jam game where I stashed everything I made into a separate folder so whatever asset I chose to import could go wherever it was made.
While it’s really useful and nice to have some separated folder for imported assets, stuff you get from the asset store doesn’t necessarily fit into what you named it and at least some assets don’t take it too kindly if you move their files around.
Also, if you play this straight, you should be safe to deal with changes when you might want to update an asset pack, or re-import it in case something got wrong with it.
As for adjustments in imported packages, the way I handle it is that I make one distinct git commit for the import into the project, and whenever some file within changes I poke around what changed and why. Sometimes it wasn’t supposed to change so I revert that particular file. Sometimes it’s a change with a prefab or something so I make a custom copy of it (or if it fits a prefab variant) so that I can track any further changes more easily within my Game part of the project.
As for general folder structure, I usually get some folders like
Animations
Materials
Models
Prefabs
Textures
In this particular project I decided to deviate from the more often used Scripts folder and call it Code instead.
The full project hierarchy thus looks like this:
Assets
Assets/Asset Packs
Assets/Asset Packs/Animations
Assets/Asset Packs/Animations/Unarmed
Assets/Asset Packs/Synty - Polygon Student Sample
Assets/Asset Packs/Synty - Polygon Student Sample/Demo Scene
Assets/Asset Packs/Synty - Polygon Student Sample/Materials
Assets/Asset Packs/Synty - Polygon Student Sample/Models
Assets/Asset Packs/Synty - Polygon Student Sample/Prefabs
Assets/Asset Packs/Synty - Polygon Student Sample/Textures
Assets/Asset Packs/Terrain Textures
Assets/Audio
Assets/Code
Assets/Game
Assets/Game/Animations
Assets/Game/Animations/Characters
Assets/Game/Environments
Assets/Game/Environments/Terrain
Assets/Materials
Assets/Prefabs
Assets/Scenes
Assets/Scenes/SandboxScene
Assets/UI
Here’s one scheme I’ve settled on…not perfect and I keep tweaking it but it works well.
First I’ll mention, I put the Sandbox Terrain in a folder named Sandbox under Scenes, along side the Sandbox scene (i.e. the folder where built lighting goes). After all, the terrain belongs to that scene and it makes no sense to put it in any other scene. (a hard lesson: I tried to “reuse” a terrain, only to find that editing it in an other scene caused it to change in the original scene…best to never reuse a terrain, but to duplicate it instead).
In my assets folder, I have a Third Party folder, so I can keep straight third party assets. I have a personal “do not touch” policy (that I sometimes violate, then pay for it later…) for them but compose/inherit or make prefab variants for if I need to modify something. I also don’t put these on Github (might be ok for a private repo) since some (most) are not open source.
I keep the original folders here. That means, for example, the polygon adventure pack, which is under “environments” has some characters in it, and they are not to be found in the characters folder. (Unity has Search Folders so I guess I could make use of that, but so far, I just remember there are characters in some environment packs).
Systems is where I put the heavy code-based asset packs, like Editor Console Pro or Easy Character Movement 2.
If I were using the student sample, which does not go in a commercial project, I’d put it in yet a separate folder, maybe “third party noncommercial”.
Then my own stuff goes under a folder with my company name and then under that, a high-level name (such as the name of the game), though other folders under the company name could be for my own asset pack creations that are meant to be reused in other projects. I “touch” those enough that it’s nontrivial to export them for other projects, though.
Within the game folder I have things like Character, Scenes, etc.
Now a Unity pet peeve…I like folder names and asset names that are more than just the 8 characters of old MS Dos days. But the only way to see the whole folder name is:
- Use list view instead of icon view (and lose big easy-to-see icons for assets)
- Click on it and look for the tiny text at the bottom of the Project window, and it’s not by itself, but the full path is given, making it harder to parse instantly. (no “expand to full name” on click like in Windows Explorer, or even hovertext, though the latter can be annoying when it pops up over where you are trying to type or click and refuses to go away…).
I wish they could let you see the full asset name.
Since I run my own Gitlab I don’t have to care so much about the licensing.
One big issue with not committing the imported assets would be that you can’t easily track if something you did in the Unity editor happens to clobber some of the stuff inside the assets.
When moving imported assets into one folder (which, depending on how you want to deal with that mentioned “asset data got changed sideways” issue above, could be added to the .gitignore list), things to keep in mind might be that some of them don’t like any changes to where they’re placed in the project, too. And updating to a newer version might not detect which items were changed and which were not (and you might want to make a commit that specifically mentioned what the asset’s update changed)…
So in an even bigger project it might be a good choice to just add a folder in which to place all project-specific things one might add (one’s own assets and scripts)… 