Informative Package Titles
|
#11
25-04-2014
I believe a package title should be a study in brevity: First the name of the Creator, preferably abbreviated to two or three characters (I used BO, myself), then a hyphen and the shortest possible complete name of the object. When there are multiple objects in a set, the first phrase after the hyphen could refer to the set name. And if an object breaks into multiple packages, such as Mesh and multiple recolors for example, then the mesh could get a 'MESH' phrase at the end, and the recolors could have 'REC'.
Still, keep each section of the name as short as possible, and don't make half a book of it. The advantage of the above structure is, that when all objects are sorted by name, objects of a single creator group together, because the same creator's identifier prepends the names. And all items of a set, and all parts of an item would also group together within that list.
Another approach that I like - but which is harder to maintain -, is to keep it even shorter than the above, and promote that the users sub-folder their downloads properly: all items of the same creator in that creator's folder, then within that folder all items of a set grouped in their own sub-folder, and parts of an item sub-foldered as well. File names don't need to be half a bible long if they're sub-foldered properly. But alas, sub-foldering requires some discipline on the downloader's part as well, and a creator can not count on that.
Sorry, if my opinion on object names is a bit of a wall of text. I just wanted to be as complete as possible :-)
In short, I like the way Fansee does it. I always try to stay close to that model as well.
Still, keep each section of the name as short as possible, and don't make half a book of it. The advantage of the above structure is, that when all objects are sorted by name, objects of a single creator group together, because the same creator's identifier prepends the names. And all items of a set, and all parts of an item would also group together within that list.
Another approach that I like - but which is harder to maintain -, is to keep it even shorter than the above, and promote that the users sub-folder their downloads properly: all items of the same creator in that creator's folder, then within that folder all items of a set grouped in their own sub-folder, and parts of an item sub-foldered as well. File names don't need to be half a bible long if they're sub-foldered properly. But alas, sub-foldering requires some discipline on the downloader's part as well, and a creator can not count on that.
Sorry, if my opinion on object names is a bit of a wall of text. I just wanted to be as complete as possible :-)
In short, I like the way Fansee does it. I always try to stay close to that model as well.
#16
25-04-2014
Looks good, Lee. I can very well live with that. But the most important is: can you?
@Klaartje : Of course, there is *some* level at which sub-foldering can become ridiculous, and can become a strain on loading times. But the most strain comes from the total length of the full filename. But though the full length is the same, I would prefer loading a whole bunch of "Creator/Setname/Object-MESH.package" files over loading a similarly long list of "Creator_Setname_Object-MESH.package" files rom the root directory. And the former is also easier to maintain, check for duplicates, corrupted files, etc.
@Klaartje : Of course, there is *some* level at which sub-foldering can become ridiculous, and can become a strain on loading times. But the most strain comes from the total length of the full filename. But though the full length is the same, I would prefer loading a whole bunch of "Creator/Setname/Object-MESH.package" files over loading a similarly long list of "Creator_Setname_Object-MESH.package" files rom the root directory. And the former is also easier to maintain, check for duplicates, corrupted files, etc.
#18
26-04-2014
Those are good package names.
The imporftant points are all addressed: clearly identifying the object and the creator, and distinguishing the mesh and the recolors. Also if it's a set with a master, you should identify the master.
Personally I hate "master-slave" in a repository set, though I don't mind "master" as a master is also a teacher or an expert.
The imporftant points are all addressed: clearly identifying the object and the creator, and distinguishing the mesh and the recolors. Also if it's a set with a master, you should identify the master.
Personally I hate "master-slave" in a repository set, though I don't mind "master" as a master is also a teacher or an expert.
#20
26-04-2014
Yeah, "repositoried" is just too long and unusual a word. Maybe "dependant" would've been a good word for it, but it's too late to change now.