Custom Scenery Exchange / Object Naming Conventions

Inspired by spacek's project I want to open a discussion about conventions in object naming. I don't want to impose any rules on object makers how they should precisely name their objects but rather summarize some conventions and good practice in naming objects. The ideas in this post stem from my experience in object making and observation of 20 years of practice of custom objects. This can be seen as a guide, but also as a beginning of a discussion.

 

What should be the goal of a good object name? What should be included?

A good object name should have the right amount of information so it can be identified without much effort. With today's possibility of the search tool in the object selection, a good object name should have the right key words so it can be found in different search cases. In my opinion, an object can have several properties:

 

-What is it? Is it a block, a statue, bush, gardens, pole, roof, peep, etc.? This key word must be included. Be general. If you create a object of tulips, still put the word flowers or gardens in there cause that is what people will look for. Also it is always good to look for similar objects and use their key word with this regard. If you make a new object that fills a niche or is variant then stress that relation to the existing ones. Of course several key words can be included. After a general keyword it is also good to then use a more precise descriptive word to specify or distinguish from other objects. In our example I would therefore use "Flowers Tulips". Also if you make a complementary object for already existing set of objects then include the keywords of that set so that people will find your new object together with those.

 

- What is its size? The size of an object or rather its outline should be included in the object. For multitile LS the format is e.g. 2x1 etc.. Fulltile objects should include the word Fulltile or 1x1. For SS objects smaller than that there has established a rather strange cascade of scales which are mathematically not consistent. I will go through a list with examples:

 

Halftile or 1/2

 

Quarter or 1/4

 

Quarter Half; 1/4 Half; Half. Here is where the obscurity starts. Instead of calling this size 1/8 cause it is 1/8th of a tile in size, the established name for this size/shape is "half" with sometimes the quarter added which technically is still correct.

 

1/8. Now this is mathematically incorrect in the sense that it is not 1/8 of a tilesize. However, it is the established name.

 

1/16. In the same manner, again mathematically incorrect.

 

Remarks: Even if here there are building blocks depicted, any object that roughly is inside of one of these sizes should state that in their name. Sometimes for diagonal pieces it makes more sense to state the size of the corresponding straight counterparts.

Special case for (Building) Blocks: whenever the size of the block is below a quarter usually a "Deco" is added into the name (replacing the "Building" if it was present in the quarter case).

 

Also the height can be added to the name, in units of clearence. This is typically only done by pieces for which there exist different versions in different heights. Usually it is given in h or ht for "heigth". Also for angled poles it is a good measure to be able to see the height of the sloped pole quicky.

 

1h; 2h; 4h

 

- What is it shape? If the object happens to be not in a box shape as in the examples of above, then it should be noted in the name. If you want to stress that your object is along the tile borders I would use the word "Straight". Typical cases are diagonals, curves and slopes (and any combination of these):

 

Diagonal

 

Half Diagonal. There are also other variants like half-diagonal, 1/2 diagonal or Tolsimir diagonal, which I would discourage to use. This angle is still quite new so I think there is a possibility to still change the convention.

 

Curved. There is also the word "Round". Curved is almost excusively used for horizontal curves while round can also apply for vertical curves (see below). The convex (more standard) case (left in pic) usually has no additional word but can go with "Outside", the concave case (right in pic)  should go with an additional "Inside".

 

For sloped pieces there hasn't really formed a convention. There are different names for different steepness of slope. My suggestion would be to use "sloped 2ht" for the respective height difference per quarter. Only exception in that case would be the shallow slope (see below). If you want to stress that your object so no slope, use the word "Flat".

 

The standard slope is a 1ht increase on a quarter. For roof object usually the slope in that case is not mentioned because that is the assumed angle. For other blocks the word "Sloped" is appropriate (without height). For fences/trims the most common words are "Slanted" or "Sloped". Slanted exclusively should be used for this angle while "sloped" as said is very general.

 

For anything with a steeper slope as the standard you should use the word "Steep". ''Steep" without height implies the angle of 2ht difference on quarter. For height differences above 6ht you can also put the word "Very" or such in front.

 

For a height difference of 1ht per fulltile, which is a slope that has become more meta in recent years the proper word is "Shallow".

 

For slopes on the diagonal you normally use the word corresponding to the slope on the straight tile border.

 

- What is the texture? What is the material? This is mostly a question only to answer when you do a building block, wall, roof, fence, path tile. Just use a descriptive word that explains your texture. This gives your object its ''character". Possible words could come from the material it represents: Brick, Wooden Planks, Mesh, Metal, Rock, Grass, Dirt, Mulch etc. Another thing to mention could be the brightness of the texture: Light, Dark. You could also think about what is the context of where the object could be used: Castle, Urban, Space, Coutries etc.. Also you could name the source of the texture if you remixed it from vanilla objects, other existing objects or even other sources. Especially when you make a set of objects with similar texture/style its important to have a good descriptive name for the set.

 

- Who made it? Even with new parkobjs having an author field, in my opinion, the creator of the object should be credited in the object name. If you made the object yourself put your name. If you remixed an existing object add your name to the ones who are already mentioned. The reason is that its often easier to remember the creator of an object but not the precise name of it.

 

Order:

The most significant information should be at the beginning. That are the keywords and the texture /style since these is the information that distinguishes it from the rest. When you're making a set then put the set style name in front so when people search for it everything is well listed. You should not start your object name with "1/4" or such. There is no consensus whether the creators name should be put in front or at the bottom. There are arguments for both: put it in front and all your objects will appear well listed and together in the selection. In past days this war important when you couldn't search for objects in the selection and had to scroll to objects. Put it at the back and your objects can go better together with other objects from other people. I do it the latter way but I don't say it's better or worse than the other way.

With the search function the order is not so much of importance anymore.

 

Final words:

A lot of times you can go just with a good keyword, descriptive name. This collection is more applicable for common type objects such as building blocks, roofs, walls, which cannot be described by a single 'block'.

 

---

This is it for now from my side. I can add more stuff, feel free to discuss anything.

 

 

 

 

Parkobj can make finding objects easier because the search feature searches the object name as well. This means there is a way to add keywords to the object without changing its display name. OpenRCT2 could improve this by searching the authors field, searching the dat identifier in the originalId field, and adding a keywords field that is searched.

 

OpenRCT2's recommended naming convention for objects is <author>.<object type>.<object name>, and they recommend using only lowercase letters for names.

 

Object type is already codified by the folder names in the official objects repository.

 

Object name can be any string now, it is not limited to 8 characters.  For the objects repository, I recommended subdividing the object name into period-separated classifications for subtype (base blocks, trims, roof, etc), material, and shape. This was partly for assisting classification of objects but also because there is no keywords field.

Good addition spacek! Thanks for the clarification!

To be clear: my discussion above was of course about the display/ingame name and not the filename. But yeah with the new file format and not the need to condense all the info into 8 letters I agree that the file name should carry enough significance info by itself.

As a small aside, I think in object finishing aligning with the conventions of NCSO is best. If descriptions and such are implemented, that’s where these specifications should go. In the display name, I think things like ‘Wooden Block’ or ‘Spanish Roof’ is what should be there. I don’t think size/shape is necessarily required there, unless an NCSO precedent is there, ala Wooden Walls getting that name instead of just Wall.

I agreee with dirt, I think renamed scenery should have more NCSO-like names, although I am not opposed to a few identifiers in the name, like quarter tile or material.

For the project, I would like to change the naming of "Diagonal" to "Triangle" for base blocks. In quarter tile, there is no distinction, but full tile triangular and diagonal blocks have different hitboxes, and I would like to adjust the naming of base blocks to match the full tile aspects.

What is the preferred abbreviation of 'deco trim,' 'deco,' 'trim,' or un-abbreviated?

Is there any significance whatsoever to the original 8-letter dat identifier, other than to a couple people who make benches? Can it be relegated to just the originalId system, or should it have more prominence in the object?

Hello All, 

I know I don't post often but this topic has me very intrigued.

 

I really think this is a great idea to maybe "standardize" the dat names using 8-characters. I actually have done something like this on my iPad just as a way to see how I would name certain things. So, for example, the Animatronic T-Rex would be AnmT-Rex.dat  Not sure if you want dashes or special characters in the dat names. Another example is AnmTrice for the Animatronic Triceratops.  There are three animatronic Skeletal Army figures, so maybe AmnSkel1, AnmSkel2, AnmSkel3.  These are simply examples. But I really do like this idea, and would be glad to offer any input into dat name ideas. Please let me know if I can be of any help.

Hello All, 

I know I don't post often but this topic has me very intrigued.

 

I really think this is a great idea to maybe "standardize" the dat names using 8-characters. I actually have done something like this on my iPad just as a way to see how I would name certain things. So, for example, the Animatronic T-Rex would be AnmT-Rex.dat  Not sure if you want dashes or special characters in the dat names. Another example is AnmTrice for the Animatronic Triceratops.  There are three animatronic Skeletal Army figures, so maybe AmnSkel1, AnmSkel2, AnmSkel3.  These are simply examples. But I really do like this idea, and would be glad to offer any input into dat name ideas. Please let me know if I can be of any help.

Unfortunately this project is about previously-created custom .DAT files and standardizing them into .parkobj objects, which are not compatible with RCTC. 

I would propose a system of what specific types or categories of objects are called in the display name.  On your example of 'deco trim' vs. 'trim' vs. 'deco' - if it's a thin horizontal bar or sloped bar, I'd refer to it as a 'trim' as all of those might not be 'deco' so to speak.  Unless you wanted to keep all the Art Deco blocks as a unit, then I'd just term them 'Art Deco Block', 'Art Deco Trim', etc.

 

So the decision would be if display names are kept as the theming unit or if they are all named individually based on their category.  Personally I prefer the latter.  The NCSO objects are generally named independent of scenery group, unless they don't have another clear name; i.e. 'Steel Wall' isn't named 'Mechanical Wall.'  

 

The problem is solving when tons of objects fall into one category, in that case.  I'd then add the basic descriptor, starting with if there's a common name for it or include material, and then proceed to theming set if there isn't anything else that fits the bill.

Unfortunately this project is about previously-created custom .DAT files and standardizing them into .parkobj objects, which are not compatible with RCTC.

Your project is, but I intended this thread to be more general also with regard on what should be considered when naming new objects. That's why I opened a new thread, too.
@matt: I don't think standardizing the 8 character DAT identifier is desirable. The only "standard" I would recommend is to introduce a 3-4 character prefix for you under which you save your objects (e.g. all my objects start with TOLS). The reason to do this is to minimize the chance of accidental double IDs. However, with the soon standard of .parkobj objects, the old 8 character IDs will be deprecated.

@dr dirt: I disagree. I think all necessary info should be in the display name. E.g like 90% of the vanilla walls are called "Wall". Targeting objects, looking for them in the object list would be made a lot more difficult if we purified the displayname. I don't see the reason why to do it apart from maybe aesthetics. In your example of "spanish roof" for instance I think that including size, shape and angle etc is really of advantage. Else you would always have to check the picture if you are looking for a specific pieces. Even if this additional info is put into some tags system of the object I don't think it solves the problem. Because that would require for you to know the tag. If all the significant info is in the name itself you can do much better "cross searches". Like for instance you have the straight spanish roof and you are looking for fitting other shapes. You type "spanish roof" and immediatly see in the list what other types are available. In your proposal you get a list of "spanish roof" and need to check each one individually by hovering over them to see the sprite.

@ spacek: I have mixed feelings about introducing new words. On one hand it may help in specifying objects like the case you brought up on the other hand it would break with the convention that has formed over the last two decades. If you started to name all diagonal blocks now as triangle then the user would have to keep in mind that now there are two expressions for the same type, causing confusion when searching for them ("was it brick block diagonal or brick block triangle?").
These consequences should be considered when introducing "standards".

I think it’s about cleanliness in the names without compromising the ease of use. Let’s take B&M supports which should be renamed to steel supports anyway: you have tons of them so the display should be simplified, and any specifics go into the descriptor. So if it’s the regular slanted pieces, options would be “Steel Support (Slanted),” or “Steel Support (Angled).” The horizontal support would be “Steel Support (Horizontal)” or “Steel Support (Crosstie).” The normal vertical supports could be “Steel Support (Vertical)” or, because they’re the most basic, just “Steel Support.” More complicated pieces would be things like Connector, Crosstie Joint, or whatever, I’m sure there’s more accurate names.

That could open up the debate for if we should go with a parenthetical format where the general form is “Basic Name (Specifier)”. If there’s sub-specifiers it would go after that, but I don’t actually know how much use that would see. You can narrow down to objects that differ only on alignment with one specifier, and then the alignment would be in the descriptor.

On the case of roofs, you get something like “Spanish Roof (Steep)” and the description can carry the inside/outside corner specification and you can look at the preview. For the eave pieces, it could look like “Spanish Roof Eave (Steep).”

For blocks I think you get the full tile, quarter tile, and quarter tile diagonal all termed “Base Block.” So you have “Wooden Base Block” for those three; the smaller shapes could be “Building Block” for things like 1/8 pieces and 1/16, etc. You still don’t end up with too many objects on a search in that case, even without adding tags. The concrete texture deviates as it has all the deco pieces, which those more specific ones would go under “Art Deco Block” or something similar.

I agree on diagonal; we shouldn’t use triangle, it isn’t clearly descriptive IMO and doesn’t have precedent.

I think by simplifying the names in this manner you would cause more confusion than what the presumed cleaniness would give. I agree that generally overly long names can clutter up things a bit but on the other hand in my opinion names should be individual. There are more than one type of wooden blocks out there, more than one type of brick and so on. So imo it makes sense to keep up the individuality so it will also be easier to talk about things. Imagine new members only knowing these 'standardized' names. It would be much more difficult to give them feedback and talk about objects. Like "I'd change the wooden base block with wooden base block here" opposed to "I'd change the wooden base block to the MK wooden base block" for instance. If additional info is only available in the object selection and not in the scenery tool ingame (aka display) it would be also a more difficult for members to be aware of and eventually learn this standard vocabular. They won't be helped if I speak of adding 1/16 deco pieces and not even know what that stands for.

 

Maybe it should be noted that I am arguing out of the perspective of NE players and don't really care about scenario play or whatever and for me it is clear that full technical info is what's needed for efficient building. I mean at my toolbox at home I also sort my hexagonal bolts by their size and don't throw them into a box labeled 'bolts'.

I agree that simplicity shouldn't be the goal here, but rather uniformity. Detail is needed for correctly identifying objects past what the default objects in the game use. Using creator names is a viable option here even if it doesn't fit from a simplicity sense.

I think those examples of textures is still doable, as to be honest, knowing them by the creator’s names is more confusing for new users of the objects to begin with. For example, Liampie’s brick texture could be named “Urban Brick Base Block” or “Urban Brick Wall” and MK’s wooden texture fits better with “Clapboard Base Block” or “Clapboard Wall”. For older members, you still have the creator field to find it or identify it.

I agree that efficient sorting is desired. As it stands, there isn’t a defined set of what size is anyways. I refer to 1/8 blocks as the half-quarter tile and 1/16 is the square quarter of a quarter tile block. I think we already have confusion in this regard and it’s rarely an issue of confusion between members at this point.

Long story short, I think texture/theme should be in the name, ie “Spanish,” “Wooden,” etc. Then what it is: “Base Block,” “Wall,” etc. Then parenthesis any sets of objects that have a large number to sort with specifiers, ie “Steep,” “Angled.” I think our point of debate is if tile shape is a reasonable specifier and I don’t think there’s enough individual objects in each set to require it but I can see the flip side. Relegating the concrete/Art Deco blocks to their own section and each texture has three base blocks (full, quarter, diagonal), five building blocks (1/8, 3/16, 1/16, 1/64, and the thick wall which is 1/16 mathematically), and two thin walls.

If you divide these into categories in the display name, you have at most 5 objects to in the most basic search for it, and you don’t even have to look at the preview as the description would have the mathematical size.

Small point of contention though, a simple (1/4 Tile) as a specifier is reasonable if not consistent with NCSO conventions.

 

When I wrote my last post, I was thinking of these two kinds of scenery as the same thing, since they both call themselves 'trim.' Taking a closer look, they aren't, but the name is confusing.

Regarding things like quarter half, quarter eighth, and quarter sixteenth, I think they all should be renamed to match their presence in the trims category. Most of them have three variants: side, inside corner, outside corner, and the naming can reflect that. Of these, there seem to be three thicknesses, with the thickest side piece being equivalent to a quarter half and the thickest outside corner piece being equivalent to a quarter eighth.