Broken communication - Lack of responses

[kamrann]

@MikeViolette;744895

Folder Structure
We have folder structure requirements for Marketplace assets that were defined based on buyer input, our means of distribution, and to keep a consistent structure for all Marketplace asset packs. We determined a standard that met the needs of the majority without limiting the needs of the few.

We decided on “ProjectName > AssetType” or “ProjectName > AssetType > SpecificAsset” because “ProjectName > SpecificAsset > AssetType” isn’t reasonable for submissions with either a large amount of assets or for submissions that don’t refer to specific assets. For instance, an environment sound pack would have a bunch of folders (one for each animal, bird, tree, water type, etc) with one or two assets in each folder. With our structure, all asset types are in one place and can be subdivided there. Using the example above, the environment sound pack can have subfolders for animals, birds, trees, and water if they want, but it’s not required.

Hi Mike.
I don’t make art packs, but this is still relevant for me when submitting plugins with blueprints and example content.

First off, “ProjectName > SpecificAsset > AssetType” will end up with exactly the same number of folders, and the same number of assets in each leaf folder, as “ProjectName > AssetType > SpecificAsset”. Now I can see your point that in some packs the distinction between specific assets is not so relevant, but I really don’t see what’s wrong with allowing either “ProjectName > AssetType”, or “ProjectName > SpecificAsset > AssetType”. It’s hardly going to leave people scratching their heads unable to find assets.

More to the point though, the engine already provides filtering by asset type. Why then enforce folder structuring by asset type too? In many (possibly most) cases, people will need to work on a bunch of logically associated assets together, rather than “all textures” or “all blueprints”. Your suggested folder structure makes that a massive pain, since obviously the engine can’t provide filtering by logical grouping due to it being dependent on the pack/project as to what that means. The reversed structure on the other hand makes it simple, and the asset type filtering allows all assets of a given type to be viewed together too, when that is desired. So it would seem to me that the reversed structure is in fact the one that meets the needs of the many.