Cross-OS file name delimiters

Pipelines
#1

Quick poll here… I’m trying to come up with a more scriptable way to define texture types in file names.

About 90% of our game textures are used as single texture 2D sprites. Diffuse color, no spec, norm, etc.
Since out pipeline is so 2D-centric, but needs to accommodate occasional realtime 3d assets, I’d like to use file name delimiters to call texture types.

My own thoughts:

  • Don’t assume “_.” suffix format. 90% of files would end in “_D” for no reason.
  • @ is used for variations of the same thing, like @2x

  • could work, but I’ve never seen it used in file names

  • ^ seems to be the best fit, but is also a regex delimiter

So my gut says “PRJ_Feature_Thing^NM.png” would be decent, with a default texture like this “PRJ_Feature_Thing.png”

#2

If you use Perforce I’d definitely avoid @ and #, those are reserved characters for filespecs. Probably a way to escape those or something but it would be a headache.

1 Like
#3

Thanks @Adam_Pletcher . I didn’t know about those… good catch.

I suppose, I could just make scripts look at the last “_suffix” of any texture and match it to a list of types with diffuse being default when it doesn’t match. Maybe I am over-complicating?

#4
  1. If you want to be cross platform, use all lower case and underscores. Other casing and punctuation is likely to cause problems somewhere down the chain across platforms and different software. In many cases you can use the double-dot for ‘extension-like’ information, eg tree_01.normal.tga
  2. Do you need the project name in the title? Won’t it be redundant from the folder structure? And won’t it make it harder to share between projects later?
  3. numbered variants work well with name_01 or name_02 etc. If you enforce name_00 for the base they will alphabetize nicely.
  4. repeating parts line normal or albedo should be similar lengths if you can to help things line up
  5. whatever you settle on, generate a folder full of 100 files using your prescribed naming screen and look at in explorer or finder or whatever. If it looks ugly or unreadable try again. Don’t write tools against it until it feels readable.
3 Likes
#5

Pretty much what has been said already. Special characters tend to get special treatment by various systems and 3rd party tools in unpredictable ways, so I avoid anything not alphanumeric.

Another cross platform gotcha is dealing with capitalized letters and camel case. /myProject/MyTextures/.. and /myproject/mytextures/.. are identical to windows systems but not unix /perforce.

I’ve found that all_lower_case_with_underscores is the least likely to break somewhere down the line, even though it annoys some teammates.

#6

I should have said we are doing Slots style free to play games. So the main app is mostly a shell and there are dozens of different slots games with varying themes and reel layouts, but similar asset needs. Not quite re-skinning, but not a whole new game engine per-project.

@Theodox - I was going to have the project name abbreviated as a prefix because assets get grabbed out of perforce by marketing or sent out to external vendors where they lose the context of their original folder tree. We have a flash-facebook version and mobile version of the game that are close enough but different enough to have their own asset pipeline, just to complicate it a little more.

I appreciate the advice on going all lower case. Having any cap-case in the name may come back to bite me, but I’m already committed to some company conventions that use caps. I don’t think I have the clout to push that big a change. As such, I’m encouraging underscores separating major categories and prefix/suffixes, then use PascalCase on descriptors for legibility. “MVM_PSE_TheThingWeMade.psd”

But as much as I can, I’ll defer to the voices of experience. I’ll avoid special character delimiters. I can write in checks in the name parsing to recognize specific suffix abbreviations.

Thank you!

#7

Just make sure to discuss this with your perforce admin. Case-insensitive and case-preserving file systems really don’t want to share a perforce server, because perforce “helpfully” gives you back a file without bothering to tell you that you are getting the wrong thing due to platform limitations.

Also – make sure you know the file path length restrictions on all your platforms. Sometimes you’ll runn into things like total path lenght < 255… and you won’t hit them until you’ve been making things for a while and changes are expensive.

If you stick with formats that support EXIF or something like that you might be able to move the semantic data into there, if you control the artist’s ability to save and export those files

#8

If you’ve running perforce in a case sensitive mode, and running on windows, invest in some defensive triggers that will block submissions on potential duplicate files and folders.

This has bitten us a few times, and I wish we could have committed to only lower_case_underscore_period.

#9

Checked with IT and the perforce server is running windows, case-insensitive so I’ll have a chat about putting in some triggers. I was going to look into triggers for things like special characters and spaces already, but that is a good recommendation, thanks. We have some legacy folders with names like “3. Production - WIP” so… yeah.

#10

You should be safe if the server is running in case-insensitive mode. Basically at that point the filename becomes metadata and the server stores everything in either upper or lower case (can’t remember which), but you shouldn’t ever get casing conflicts.