UE4 Project / Content Style Guide

I created a UE4 style guide that gained a small bit of traction, so thought I’d post it here.

I use it on all company internal projects as well as client projects when clients do not have their own style guide.

It is hosted on GitHub, and I’d like to encourage you to create your own fork and modify it to your own standards. If you spot any errors or feel like something should be added, please submit a pull request.

This style guide is a continuous work in progress and will be expanded on over time.

There is also a UE4 marketplace plugin that automates lint checks to make sure you are adhering to the style guide, available at Linter in Code Plugins - UE Marketplace .

We recently began cleaning up many of our our assets based on this guide.
I recommend anyone who hasn’t thought about such things to check it out sooner rather then later.

@Allar I didn’t realise there was a plugin until recently but will be using it to continue cleaning things up once we’re able.
Thank you for both the guide & the plugin.

This is wonderful. You are wonderful.

(I refuse to use capital letters in filenames (C/C++/C#-enforced excepted) personally and my team must adhere to my OCD on that, but the general gist of this is ace).

Cool stuff, I really like the idea and hope the style guide continues to thrive.

I have a few questions:

  1. What is the benefit of the prefix and suffixes for assets when, as you say yourself in the guide, you can easily filter out all this stuff using the content browers filter options? I think an explanation in the guide about the benefits would be helpful. I myself am a little bit skeptical about this as I am a programmer and know this kind of naming as hungarian notation. It is considered useless/bad practice nowadays because the tools show you this information anyway so it’s redundant. Interested to hear what the reasoning is for UE, though. :slight_smile:
  2. Where would character art go? Directly into the Characters folder or into the Art folder?
  3. Where to put music? Does this count as “art” or is art for intended visual stuff?
  4. Where would you put User Interface stuff? Does this belong to Art?

That’s it for now, looking forward to the answers.

  1. Definitely a fair question. Prefixes and suffixes are used because having assets with the same name on disk is simply either a) a bad idea or b) disallowed by the engine. There are some cases where you can have multiple assets in the same on disk file and share the same name if they are different asset types but this is a technical exception and relying on this exception makes things annoying to work with. Also prefixes and suffixes tend to create shorter names than an additional folder, and if you’ve ever worked with a massive project you might find that its not too hard to end up with ‘filename is too long’ errors. Lastly, if an engineer has to make a reference to an asset in text form for a myriad of reasons, it is easier to instantly recognize what type an asset is (especially for references that don’t have the asset type auto attached).

  2. Character art, in my mind, would go into a Characters folder and then that folder would have sub folders based on the character’s ‘code name’. For example, “Bob”, “MechBoss”, etc. The reason for a ‘code name’ here is that if your character is named ‘Dr. John Williams V Esq.’, that would make a terrible asset name.

  3. Music and audio is one of the more weaker defined style requirements in my guide. I don’t work with large swaths of audio to know the best way to sort them, so I’m eager for feedback on it. What I have been doing is creating a Music folder and then subfolders based on how music is sorted, i.e. if there are 10 tracks for a level, I’d group them by level name. If its a dynamically composed score, I’d create sub folders like ‘Bases’, ‘Stingers’, ‘Action’, ‘CoolOffs’, etc.

  4. UI is also another weakly specified style. I put all UI assets in a folder called UI, and then create sub folders based on asset purpose. For commonly used things, I use a folder called ‘Widgets’. For things that are menu specific, I use a folder named after that menu i.e. “LobbyScreen”.

All feedback is appreciated.

Hi Allar,

thanks for the elaborate answers. The explanation for prefixes and suffices makes sense, so I will stick to them. :slight_smile:

Another thing I noticed today, starting to work with Substance Designer & Painter: There is a suffix missing for metallic texture maps. Since _M is already taken, what suffix would you give it?
The epic guidelines use _MT. Speaking of which, I am interested in why you decided to use different prefixes and suffixes than epic.

Cheers
Michael

Most of the choices were based off the ‘average’ of Epic example content, docs, and the majority of professional client work I’ve done across various studios. Epic doesn’t follow their own guidelines a good part of the time as well, often having meshes without a prefix, some with the S_ prefix, some with SM_, etc.

In places I found Epic to be inconsistent, I gave more weight to ‘what I’m used to seeing out in the world’. The goal is definitely not to introduce new radical concepts or change some paradigms, but to find a common base we can all speak.

In practice I found ‘metallic maps’ are extremely rare, as usually you push the value to 0 or 1. In things that require a combination of 0 and 1 values, this map is usually packed into a texture that contains other pieces of data for the sake of memory and performance. Packing a roughness, metallic, and any other single channel data together is definitely the way to go. It is unfortunate that many bulk texture services don’t pre-pack these channels for you. A packed texture might read something like T_CargoCrate_RMM, for ‘Roughness, Metallic, Mask’. It is true that packing a metallic channel and a mask channel together is somewhat ambiguous, however also in practice I’ve found metallic generally gets packed before mask, in the rare situation that both channels exist. If you require a metallic map, generally the metallic map also makes a great mask, unless you’re masking something seperately.

In any case, when it comes to the very technical nature of texture packing, the guide could definitely elaborate more on it. I plan to have a section specifically for textures in the future, but I’m hoping a tech artist who knows more about the subject would step up and help shell it out.

Also:

If this guide has helped anyone in any way, please consider voting for the complimentary plugin Linter in the December Community Poll. It only takes 10 seconds and it’ll help quite a bit! Thanks!