DOCSEARCHbyAlgolia
Submit Docs

UE5 Style Guide

repository·main·Indexed 27 days ago

https://github.com/allar/ue5-style-guide

A comprehensive style guide for Unreal Engine 4 and UE5 designed to enforce consistency in code, assets, and project structure. It provides detailed naming conventions for identifiers, folder structures, and Blueprint variables, as well as a standardized asset naming pattern (Prefix_BaseAssetName_Variant_Suffix) with specific modifiers for meshes, materials, textures, animations, AI, and sound assets.

Tokens
13K
Snippets
8
Records
91
Agent score
92%

What's inside ue5-style-guide

  1. Core Principles of the UE4 Style Guide

    main

    The style guide is built on several foundational principles to ensure project consistency and professional standards:

    • Respect existing guides: If a project already has a style guide, follow it instead of this one. Style guides should be living documents that evolve through proposals.
    • Unified authorship appearance: All structure, assets, and code should look as if a single person created them, regardless of the number of contributors. This minimizes guesswork and cognitive load.
    • Enforce consistency: Correct work that deviates from the style guide to maintain team productivity and ease of assistance (e.g., avoiding 'Blueprint spaghetti').
    • Legal compliance: Do not introduce illegal actions, such as distributing content without rights, infringing on copyrights/trademarks, or failing to follow licensing/attribution requirements.

  2. Use Linter for automated UE4 project scanning

    main
    Linter is an Unreal Engine 4 plugin available on the Unreal Engine Marketplace. It performs automated scanning and reporting of a UE4 project's adherence to style guide standards by scanning project content using programmatic rulesets. It identifies instances where project assets or code do not follow defined rules.

  3. Understand Linter Rule Set Structure

    main

    A LintRuleSet is a Data Asset that defines the rules used when scanning a project. It consists of two main components:

    1. NamingConvention Data Asset: A list of naming conventions used by rules for validation.
    2. Class Lint Rules Map: A map of Unreal Engine 4 classes paired with a list of LintRules (assets).

    When linting, the engine scans objects using the rules matching the "most specific" class defined in the map.

    Note on UObjects: The UE4 editor does not allow UObject as a key in the Class Lint Rules Map. To define rules for all UObjects, use the AnyObject_LinterDummyClass class instead.

  4. Link to specific sections of the Style Guide

    main
    Every section of the Style Guide is numbered to allow direct linking. You can link to a specific section by appending a hashtag and the section number to the URL http://ue4.style. For example, to link to the first principle, use http://ue4.style#0.1.

  6. Follow the Base Asset Name pattern

    main

    All assets should follow a standardized naming pattern to ensure they can be easily managed, searched, and maintained. The pattern is:

    Prefix_BaseAssetName_Variant_Suffix

    • Prefix: An acronym of the asset type (e.g., SK_ for Skeletal Mesh).
    • BaseAssetName: A short, recognizable name representing the logical group (e.g., Bob for all assets related to a character named Bob).
    • Variant:
      • For specific/named variations: Use a recognizable name (e.g., Bob_Evil).
      • For generic variations: Use a two-digit number starting at 01 (e.g., Rock_01). Avoid three-digit numbers; if you exceed 100 assets, reorganize the base names.
      • For chained variants: You can stack names (e.g., Flooring_Marble_01).
    • Suffix: Determined by the asset type (e.g., _D for Diffuse texture).
    Prefix_BaseAssetName_Variant_Suffix

  7. Blueprint Function Best Practices

    main

    To maintain readable and debuggable Blueprints:

    • Return Nodes: Every function must have an explicit Return node to clearly define execution flow.
    • Node Limit: No single function should exceed 50 nodes. If a function is larger, break it down into smaller sub-functions. (Note: Comment, Route, Cast, Get Variable, Break Struct, Function Entry, and Self nodes do not count toward this limit).
    • Public Descriptions: All Public functions should have a description filled out in the metadata.
    • Plugin Functions: BlueprintCallable functions in a plugin should be categorized by the plugin's name (e.g., PluginName | SubCategory).

  8. Blueprint Compilation Standards

    main
    All Blueprints must compile with zero warnings and zero errors. Warnings and errors must be fixed immediately to prevent unexpected behavior. Do not commit corrupted projects to source control; instead, archive them. Corrupted projects cause broken references, unexpected behavior, and frequent unnecessary recompilation.

  9. Naming conventions for folders

    main

    When naming folders in the Unreal Engine content structure, follow these rules to ensure compatibility with engineering tools and build processes:

    • Use PascalCase: Start with an uppercase letter and capitalize the first letter of every subsequent word (e.g., DesertEagle, RocketPistol).
    • No Spaces: Never use spaces in folder names, as they can cause failures in batch processes and engineering tools. Ideally, the project root should also avoid spaces (e.g., D:\Project instead of C:\Users\My Name\Documents).
    • No Unicode or Special Characters: Avoid Unicode characters (e.g., use Zoe instead of Zoë) and special symbols like @, -, _, ,, *, or #. These can cause unexpected issues with source control, cross-platform compatibility, and engine tools.

  10. Follow the Asset Naming Convention Pattern

    main

    All assets in an Unreal Engine 4 project should follow a consistent naming pattern to ensure they are easily searchable and maintainable. The standard pattern is:

    Prefixo_NomeBaseDoAsset_Variante_Sufixo

    • Prefixo (Prefix): An acronym representing the asset type (e.g., SK_ for Skeletal Mesh).
    • NomeBaseDoAsset (Base Asset Name): A short, recognizable name related to the logical group (e.g., Bob).
    • Variante (Variant):
      • For specific subsets, use a recognizable name (e.g., Evil for Bob_Evil).
      • For generic variations, use a two-digit number starting at 01 (e.g., Rocha_01). Avoid three-digit numbers; if you exceed 100 assets, use different base names.
      • Variants can be chained (e.g., Piso_Marmore_01).
    • Sufixo (Suffix): Determined by the asset type or specific data channel (e.g., _D for Diffuse).
    // Example: Bob (Character)
SK_Bob
M_Bob
T_Bob_D
T_Bob_N
T_Bob_Evil_D

// Example: Rocha (Rock)
S_Rocha_01
S_Rocha_02
M_Rocha
MI_Rocha_Neve

  11. Use the Developers folder for local testing

    main

    Use the Developers folder as a 'sandbox' for team members to experiment with assets without risking the main project structure.

    Workflow for promoting assets:

    1. Create and iterate on assets within a Developers sub-folder.
    2. Once the assets are production-ready, move them to the appropriate project-specific folder.
    3. Fix up redirectors to ensure references are updated.

    Note: The Content Browser can be configured to hide Developers folders by default, preventing accidental usage of experimental assets by other team members (like world designers).

  12. Organize large asset sets (Animations and Audio)

    main

    As an exception to the rule against type-based folders, assets that come in large, highly related volumes should be grouped together.

    Guidelines:

    • Animations and Audio: If you have more than 15 related assets (e.g., animations for a specific character), group them together (e.g., Characters/Common/Animations).
    • Textures and Materials: Do not use this rule for textures and materials. These should be organized by their functional context (e.g., Environment/Rocks/) rather than by type.