{"id":15032295,"url":"https://github.com/allar/ue5-style-guide","last_synced_at":"2026-02-04T08:01:48.554Z","repository":{"id":37570308,"uuid":"63004853","full_name":"Allar/ue5-style-guide","owner":"Allar","description":"An attempt to make Unreal Engine 4 projects more consistent","archived":false,"fork":false,"pushed_at":"2023-10-05T18:32:26.000Z","size":849,"stargazers_count":5753,"open_issues_count":45,"forks_count":1218,"subscribers_count":214,"default_branch":"main","last_synced_at":"2025-06-25T13:53:06.870Z","etag":null,"topics":["blueprint","lint","linter","linters","linting","naming-conventions","style-guide","styleguide","udk","udk4","ue4","unreal","unreal-engine","unreal-engine-4","unreal-marketplace","unrealengine"],"latest_commit_sha":null,"homepage":"http://ue5.style","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Allar.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"github":"ALLAR"}},"created_at":"2016-07-10T15:18:14.000Z","updated_at":"2025-06-25T09:15:48.000Z","dependencies_parsed_at":"2024-07-31T04:33:59.678Z","dependency_job_id":"3daae371-7712-4303-976f-e83028bc2443","html_url":"https://github.com/Allar/ue5-style-guide","commit_stats":null,"previous_names":["allar/ue4-style-guide"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/Allar/ue5-style-guide","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Allar%2Fue5-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Allar%2Fue5-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Allar%2Fue5-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Allar%2Fue5-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Allar","download_url":"https://codeload.github.com/Allar/ue5-style-guide/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Allar%2Fue5-style-guide/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":265151840,"owners_count":23719123,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blueprint","lint","linter","linters","linting","naming-conventions","style-guide","styleguide","udk","udk4","ue4","unreal","unreal-engine","unreal-engine-4","unreal-marketplace","unrealengine"],"created_at":"2024-09-24T20:17:56.977Z","updated_at":"2026-02-04T08:01:48.469Z","avatar_url":"https://github.com/Allar.png","language":null,"funding_links":["https://github.com/sponsors/ALLAR"],"categories":[],"sub_categories":[],"readme":"# [Gamemakin](https://gamemak.in) UE4 Style Guide() {\n\n*A mostly reasonable approach to Unreal Engine 4*\n\nHeavily inspired by the [Airbnb Javascript Style Guide](https://github.com/airbnb/javascript).\n\n[![Analytics](https://ga-beacon.appspot.com/UA-80567399-1/repo?useReferrer)](#)\n\n## Repo Notice\n\nThis repo is now located at https://github.com/Allar/ue5-style-guide. The default branch of this repository has been renamed `main`.\n\n## This is currently for UE4. For UE5/v2, see the v2 branch\n## Linter and Style Guide Documentation\n\nMore technical documentation regarding Linter and the Style Guide can be found at our [ReadTheDocs](https://ue4-style-guide.readthedocs.io/en/latest/) page.\n\n## Discuss This Style Guide\n\nGamemakin LLC has a public Discord channel at http://discord.gamemak.in with a #linter channel if you'd like to discuss all things style guide and Linter plugin.\n\n## Linking To This Document\n\nEvery section of this style guide is numbered for both easy reference and easy linking. You can link to any section directly by simply append a hash tag and the section number to the end of http://ue4.style\nFor example, if you want to send someone to the first principle of this style guide you would append `#0.1`, resulting in http://ue4.style#0.1.\n\n## Forks And Translations\n\nIf you have made a notable fork or translation that is not suitable for a pull request into this repo, please submit a pull request to add the fork or translation here.\n\n* [Korean Translation](https://github.com/ymkim50/ue4-style-guide/blob/master/README_Kor.md) by ymkim50\n* [Russian Translation](https://github.com/CosmoMyzrailGorynych/ue4-style-guide-rus/blob/master/README.md) by CosmoMyzrailGorynych\n* [Japanese Translation](https://github.com/akenatsu/ue4-style-guide/blob/master/README.jp.md) by akenatsu\n* [Chinese Translation](https://github.com/skylens-inc/ue4-style-guide/blob/master/README.md) by Beijing Skylens Tech.\n* [Brazilian Portuguese Translation](https://github.com/danlvr/ue5-style-guide/blob/main/README_PTBR.md) by danlvr.\n* [French Translation](https://github.com/Arnaud58/ue5-style-guide/blob/main/README.md) by Arnaud58\n\n## Table of contents\n- [Important Terminology](#important-terminology)\n - [Levels/Maps](#terms-level-map)\n - [Identifiers](#terms-identifiers)\n - [Cases](#terms-cases)\n - [Variables / Properties](#terms-var-prop)\n - [Property](#terms-property)\n - [Variable](#terms-variable)\n- [0. Principles](#0)\n - [0.1 If your UE4 project already has a style guide, you should follow it](#0.1)\n - [0.2 All structure, assets, and code in any Unreal Engine 4 project should look like a single person created it, no matter how many people contributed](#0.2)\n - [0.3 Friends do not let friends have bad style](#0.3)\n - [0.4 A team without a style guide is no team of mine](#0.4)\n - [0.5 Don't Break The Law](#0.5)\n- [00. Globally Enforced Opinions](#00)\n - [00.1 Forbidden Characters](#00.1)\n - [Identifiers](#identifiers)\n- [1. Asset Naming Conventions](#anc)\n - [1.1 Base Asset Name - `Prefix_BaseAssetName_Variant_Suffix`](#base-asset-name)\n - [1.1 Examples](#1.1-examples)\n - [1.2 Asset Name Modifiers](#asset-name-modifiers)\n - [1.2.1 Most Common](#anc-common)\n - [1.2.2 Animations](#anc-animations)\n - [1.2.3 Artificial Intelligence](#anc-ai)\n - [1.2.4 Blueprints](#anc-bp)\n - [1.2.5 Materials](#anc-materials)\n - [1.2.6 Textures](#anc-textures)\n - [1.2.6.1 Texture Packing](#anc-textures-packing)\n - [1.2.7 Miscellaneous](#anc-misc)\n - [1.2.8 Paper 2D](#anc-paper2d)\n - [1.2.9 Physics](#anc-physics)\n - [1.2.10 Sounds](#anc-sounds)\n - [1.2.11 User Interface](#anc-ui)\n - [1.2.12 Effects](#anc-effects)\n- [2. Content Directory Structure](#structure)\n - [2e1 Example Project Content Structure](#2e1)\n - [2.1 Folder Names](#structure-folder-names)\n - [2.1.1 Always Use PascalCase](#2.1.1)\n - [2.1.2 Never Use Spaces](#2.1.2)\n - [2.1.3 Never Use Unicode Characters And Other Symbols](#2.1.3)\n - [2.2 Use A Top Level Folder For Project Specific Assets](#structure-top-level)\n - [2.2.1 No Global Assets](#2.2.1)\n - [2.2.2 Reduce Migration Conflicts](#2.2.2)\n - [2.2.2e1 Master Material Example](#2.2.2e1)\n - [2.2.3 Samples, Templates, and Marketplace Content Are Risk-Free](#2.2.3)\n - [2.2.4 DLC, Sub-Projects, and Patches Are Easily Maintained](#2.2.4)\n - [2.3 Use Developers Folder For Local Testing](#structure-developers)\n - [2.4 All Map\u003csup\u003e*\u003c/sup\u003e Files Belong In A Folder Called Maps](#structure-maps)\n - [2.5 Use A `Core` Folder For Critical Blueprints And Other Assets](#structure-core)\n - [2.6 Do Not Create Folders Called `Assets` or `AssetTypes`](#structure-assettypes)\n - [2.6.1 Creating a folder named `Assets` is redundant](#2.6.1)\n - [2.6.2 Creating a folder named `Meshes`, `Textures`, or `Materials` is redundant](#2.6.2)\n - [2.7 Very Large Asset Sets Get Their Own Folder Layout](#structure-large-sets)\n - [2.8 `MaterialLibrary`](#structure-material-library)\n - [2.9 No Empty Folders](#structure-no-empty-folders)\n- [3. Blueprints](#bp)\n - [3.1 Compiling](#bp-compiling)\n - [3.2 Variables](#bp-vars)\n - [3.2.1 Naming](#bp-var-naming)\n - [3.2.1.1 Nouns](#bp-var-naming-nouns)\n - [3.2.1.2 PascalCase](#bp-var-naming-case)\n - [3.2.1.2e Examples](#3.2.1.2e)\n - [3.2.1.3 Boolean `b` Prefix](#bp-var-bool-prefix)\n - [3.2.1.4 Boolean Names](#bp-var-bool-names)\n - [3.2.1.4.1 General And Independent State Information](#3.2.1.4.1)\n - [3.2.1.4.2 Complex States](#3.2.1.4.2)\n - [3.2.1.5 Considered Context](#bp-vars-naming-context)\n - [3.2.1.5e Examples](#3.2.1.5e)\n - [3.2.1.6 Do _Not_ Include Atomic Type Names](#bp-vars-naming-atomic)\n - [3.2.1.7 Do Include Non-Atomic Type Names](#bp-vars-naming-complex)\n - [3.2.1.8 Arrays](#bp-vars-naming-arrays)\n - [3.2.2 Editable Variables](#bp-vars-editable)\n - [3.2.2.1 Tooltips](#bp-vars-editable-tooltips)\n - [3.2.2.2 Slider And Value Ranges](#bp-vars-editable-ranges)\n - [3.2.3 Categories](#bp-vars-categories)\n - [3.2.4 Variable Access Level](#bp-vars-access)\n - [3.2.4.1 Private Variables](#bp-vars-access-private)\n - [3.2.5 Advanced Display](#bp-vars-advanced)\n - [3.2.6 Transient Variables](#bp-vars-transient)\n - [3.2.8 Config Variables](#bp-vars-config)\n - [3.3 Functions, Events, and Event Dispatchers](#bp-functions)\n - [3.3.1 Function Naming](#bp-funcs-naming)\n - [3.3.1.1 All Functions Should Be Verbs](#bp-funcs-naming-verbs)\n - [3.3.1.2 Property RepNotify Functions Always `OnRep_Variable`](#bp-funcs-naming-onrep)\n - [3.3.1.3 Info Functions Returning Bool Should Ask Questions](#bp-funcs-naming-bool)\n - [3.3.1.4 Event Handlers and Dispatchers Should Start With `On`](#bp-funcs-naming-eventhandlers)\n - [3.3.1.5 Remote Procedure Calls Should Be Prefixed With Target](#bp-funcs-naming-rpcs)\n - [3.3.2 All Functions Must Have Return Nodes](#bp-funcs-return)\n - [3.3.3 No Function Should Have More Than 50 Nodes](#bp-graphs-funcs-node-limit)\n - [3.3.4 All Public Functions Should Have A Description](#bp-graphs-funcs-description)\n - [3.3.5 All Custom Static Plugin `BlueprintCallable` Functions Must Be Categorized By Plugin Name](#bp-graphs-funcs-plugin-category)\n - [3.4 Blueprint Graphs](#bp-graphs)\n - [3.4.1 No Spaghetti](#bp-graphs-spaghetti)\n - [3.4.2 Align Wires Not Nodes](#bp-graphs-align-wires)\n - [3.4.3 White Exec Lines Are Top Priority](#bp-graphs-exec-first-class)\n - [3.4.4 Graphs Should Be Reasonably Commented](#bp-graphs-block-comments)\n - [3.4.5 Graphs Should Handle Casting Errors Where Appropriate](#bp-graphs-cast-error-handling)\n - [3.4.6 Graphs Should Not Have Any Dangling / Loose / Dead Nodes](#bp-graphs-dangling-nodes)\n- [4. Static Meshes](#4)\n - [4.1 Static Mesh UVs](#s-uvs)\n - [4.1.1 All Meshes Must Have UVs](#s-uvs-no-missing)\n - [4.1.2 All Meshes Must Not Have Overlapping UVs for Lightmaps](#s-uvs-no-overlapping)\n - [4.2 LODs Should Be Set Up Correctly](#s-lods)\n - [4.3 Modular Socketless Assets Should Snap To The Grid Cleanly](#s-modular-snapping)\n - [4.4 All Meshes Must Have Collision](#s-collision)\n - [4.5 All Meshes Should Be Scaled Correctly](#s-scaled)\n- [5. Niagara](#Niagara)\n - [5.1 No Spaces, Ever](#ng-rules)\n- [6. Levels / Maps](#levels)\n - [6.1 No Errors Or Warnings](#levels-no-errors-or-warnings)\n - [6.2 Lighting Should Be Built](#levels-lighting-should-be-built)\n - [6.3 No Player Visible Z Fighting](#levels-no-visible-z-fighting)\n - [6.4 Marketplace Specific Rules](#levels-mp-rules)\n - [6.4.1 Overview Level](#levels-mp-rules-overview)\n - [6.4.2 Demo Level](#levels-mp-rules-demo)\n- [7. Textures](#textures)\n - [7.1 Dimensions Are Powers of 2](#textures-dimensions)\n - [7.2 Texture Density Should Be Uniform](#textures-density)\n - [7.3 Textures Should Be No Bigger than 8192](#textures-max-size)\n - [7.4 Textures Should Be Grouped Correctly](#textures-group)\n\n## Important Terminology\n\n\u003ca name=\"terms-level-map\"\u003e\u003c/a\u003e\n##### Levels/Maps\n\nThe word 'map' generally refers to what the average person calls a 'level' and may be used interchangeably. See this term's history [here](https://en.wikipedia.org/wiki/Level_(video_gaming)).\n\n\u003ca name=\"terms-identifiers\"\u003e\u003c/a\u003e\n##### Identifiers\nAn `Identifier` is anything that resembles or serves as a \"name\". For example, the name of an asset, or the name of a material later, or a blueprint property, a variable, or a folder name, or for a data table row name, etc...\n\n\u003ca name=\"terms-cases\"\u003e\u003c/a\u003e\n##### Cases\n\nThere are a few different ways you can `CaseWordsWhenNaming`. Here are some common casing types:\n\n\u003e ###### PascalCase\n\u003e\n\u003e Capitalize every word and remove all spaces, e.g. `DesertEagle`, `StyleGuide`, `ASeriesOfWords`.\n\u003e\n\u003e ###### camelCase\n\u003e\n\u003e The first letter is always lowercase but every following word starts with uppercase, e.g. `desertEagle`, `styleGuide`, `aSeriesOfWords`.\n\u003e\n\u003e ###### Snake_case\n\u003e\n\u003e Words can arbitrarily start upper or lowercase but words are separated by an underscore, e.g. `desert_Eagle`, `Style_Guide`, `a_Series_of_Words`.\n\n\u003ca name=\"terms-var-prop\"\u003e\u003c/a\u003e\n##### Variables / Properties\n\nThe words 'variable' and 'property' in most contexts are interchangable. If they are both used together in the same context however:\n\n\u003ca name=\"terms-property\"\u003e\u003c/a\u003e\n###### Property\nUsually refers to a variable defined in a class. For example, if `BP_Barrel` had a variable `bExploded`, `bExploded` may be referred to as a property of `BP_Barrel`.\n\nWhen in the context of a class, it is often used to imply accessing previously defined data.\n\n\u003ca name=\"terms-variable\"\u003e\u003c/a\u003e\n###### Variable\nUsually refers to a variable defined as a function argument or a local variable inside a function.\n\nWhen in the context of a class, it is often used to convey discussion about its definition and what it will hold.\n\n\u003ca name=\"0\"\u003e\u003c/a\u003e\n## 0. Principles\n\nThese principles have been adapted from [idomatic.js style guide](https://github.com/rwaldron/idiomatic.js/).\n\n\u003ca name=\"0.1\"\u003e\u003c/a\u003e\n### 0.1 If your UE4 project already has a style guide, you should follow it\n\nIf you are working on a project or with a team that has a pre-existing style guide, it should be respected. Any inconsistency between an existing style guide and this guide should defer to the existing.\n\nStyle guides should be living documents. You should propose style guide changes to an existing style guide as well as this guide if you feel the change benefits all usages.\n\n\u003e #### \"Arguments over style are pointless. There should be a style guide, and you should follow it.\"\n\u003e [_Rebecca Murphey_](https://rmurphey.com)\n\n\u003ca name=\"0.2\"\u003e\u003c/a\u003e\n### 0.2 All structure, assets, and code in any Unreal Engine 4 project should look like a single person created it, no matter how many people contributed\n\nMoving from one project to another should not cause a re-learning of style and structure. Conforming to a style guide removes unneeded guesswork and ambiguities.\n\nIt also allows for more productive creation and maintenance as one does not need to think about style. Simply follow the instructions. This style guide is written with best practices in mind, meaning that by following this style guide you will also minimize hard to track issues.\n\n\u003ca name=\"0.3\"\u003e\u003c/a\u003e\n### 0.3 Friends do not let friends have bad style\n\nIf you see someone working either against a style guide or no style guide, try to correct them.\n\nWhen working within a team or discussing within a community such as [Unreal Slackers](http://join.unrealslackers.org/), it is far easier to help and to ask for help when people are consistent. Nobody likes to help untangle someone's Blueprint spaghetti or deal with assets that have names they can't understand.\n\nIf you are helping someone whose work conforms to a different but consistent and sane style guide, you should be able to adapt to it. If they do not conform to any style guide, please direct them here.\n\n\u003ca name=\"0.4\"\u003e\u003c/a\u003e\n### 0.4 A team without a style guide is no team of mine\n\nWhen joining an Unreal Engine 4 team, one of your first questions should be \"Do you have a style guide?\". If the answer is no, you should be skeptical about their ability to work as a team.\n\n\u003ca name=\"0.5\"\u003e\u003c/a\u003e\n### 0.5 Don't Break The Law\n\nGamemakin LLC is not a lawyer, but please don't introduce illegal actions and behavior to a project, including but not limited to:\n\n* Don't distribute content you don't have the rights to distribute\n* Don't infringe on someone else's copyrighted or trademark material\n* Don't steal content\n* Follow licensing restrictions on content, e.g. attribute when attributions are needed\n\n\u003ca name=\"00\"\u003e\u003c/a\u003e\n## 00. Globally Enforced Opinions\n\n@TODO: Make this section 1 and update this document accordingly. Or maybe we don't?\n\n\u003ca name=\"00.1\"\u003e\u003c/a\u003e\n### 00.1 Forbidden Characters\n\n\u003ca name=\"identifiers-1\"\u003e\u003c/a\u003e\n#### Identifiers\n\nIn any `Identifier` of any kind, **never** use the following unless absolutely forced to:\n\n* White space of any kind\n* Backward slashes `\\`\n* Symbols i.e. `#!@$%`\n* Any Unicode character\n\nAny `Identifier` should strive to only have the following characters when possible (the RegEx `[A-Za-z0-9_]+`)\n\n* ABCDEFGHIJKLMNOPQRSTUVWXYZ\n* abcdefghijklmnopqrstuvwxyz\n* 1234567890\n* _ (sparingly)\n\nThe reasoning for this is this will ensure the greatest compatibility of all data across all platforms across all tools, and help prevent downtime due to potentially bad character handling for identifiers in code you don't control.\n\n\u003ca name=\"anc\"\u003e\u003c/a\u003e\n\u003ca name=\"1\"\u003e\u003c/a\u003e\n## 1. Asset Naming Conventions\n\nNaming conventions should be treated as law. A project that conforms to a naming convention is able to have its assets managed, searched, parsed, and maintained with incredible ease.\n\nMost things are prefixed with prefixes being generally an acronym of the asset type followed by an underscore.\n\n\u003ca name=\"base-asset-name\"\u003e\u003c/a\u003e\n\u003ca name=\"1.1\"\u003e\u003c/a\u003e\n### 1.1 Base Asset Name - `Prefix_BaseAssetName_Variant_Suffix`\n\nAll assets should have a _Base Asset Name_. A Base Asset Name represents a logical grouping of related assets. Any asset that is part of this logical group should follow the standard of `Prefix_BaseAssetName_Variant_Suffix`.\n\nKeeping the pattern `Prefix_BaseAssetName_Variant_Suffix` and in mind and using common sense is generally enough to warrant good asset names. Here are some detailed rules regarding each element.\n\n`Prefix` and `Suffix` are to be determined by the asset type through the following [Asset Name Modifier](#asset-name-modifiers) tables.\n\n`BaseAssetName` should be determined by a short and easily recognizable name related to the context of this group of assets. For example, if you had a character named Bob, all of Bob's assets would have the `BaseAssetName` of `Bob`.\n\nFor unique and specific variations of assets, `Variant` is either a short and easily recognizable name that represents logical grouping of assets that are a subset of an asset's base name. For example, if Bob had multiple skins these skins should still use `Bob` as the `BaseAssetName` but include a recognizable `Variant`. An 'Evil' skin would be referred to as `Bob_Evil` and a 'Retro' skin would be referred to as `Bob_Retro`.\n\nFor unique but generic variations of assets, `Variant` is a two digit number starting at `01`. For example, if you have an environment artist generating nondescript rocks, they would be named `Rock_01`, `Rock_02`, `Rock_03`, etc. Except for rare exceptions, you should never require a three digit variant number. If you have more than 100 assets, you should consider organizing them with different base names or using multiple variant names.\n\nDepending on how your asset variants are made, you can chain together variant names. For example, if you are creating flooring assets for an Arch Viz project you should use the base name `Flooring` with chained variants such as `Flooring_Marble_01`, `Flooring_Maple_01`, `Flooring_Tile_Squares_01`.\n\n\u003ca name=\"1.1-examples\"\u003e\u003c/a\u003e\n#### 1.1 Examples\n\n##### 1.1e1 Bob\n\n| Asset Type | Asset Name |\n| ----------------------- | ---------------------------------------------------------- |\n| Skeletal Mesh | SK_Bob |\n| Material | M_Bob |\n| Texture (Diffuse/Albedo)| T_Bob_D |\n| Texture (Normal) | T_Bob_N |\n| Texture (Evil Diffuse) | T_Bob_Evil_D |\n\n##### 1.1e2 Rocks\n\n| Asset Type | Asset Name |\n| ----------------------- | ---------------------------------------------------------- |\n| Static Mesh (01) | S_Rock_01 |\n| Static Mesh (02) | S_Rock_02 |\n| Static Mesh (03) | S_Rock_03 |\n| Material | M_Rock |\n| Material Instance (Snow)| MI_Rock_Snow |\n\n\u003ca name=\"asset-name-modifiers\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2\"\u003e\u003c/a\u003e\n### 1.2 Asset Name Modifiers\n\nWhen naming an asset, use these tables to determine the prefix and suffix to use with an asset's [Base Asset Name](#base-asset-name).\n\n\u003ca name=\"anc-common\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.1\"\u003e\u003c/a\u003e\n#### 1.2.1 Most Common\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Level / Map | | | [Should be in a folder called Maps.](#2.4) |\n| Level (Persistent) | | _P | |\n| Level (Audio) | | _Audio | |\n| Level (Lighting) | | _Lighting | |\n| Level (Geometry) | | _Geo | |\n| Level (Gameplay) | | _Gameplay | |\n| Blueprint | BP_ | | |\n| Material | M_ | | |\n| Static Mesh | S_ | | Many use SM_. We use S_. |\n| Skeletal Mesh | SK_ | | |\n| Texture | T_ | _? | See [Textures](#anc-textures) |\n| Particle System | PS_ | | |\n| Widget Blueprint | WBP_ | | |\n\n\u003ca name=\"anc-animations\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.2\"\u003e\u003c/a\u003e\n#### 1.2.2 Animations\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Aim Offset | AO_ | | |\n| Aim Offset 1D | AO_ | | |\n| Animation Blueprint | ABP_ | | |\n| Animation Composite | AC_ | | |\n| Animation Montage | AM_ | | |\n| Animation Sequence | A_ | | |\n| Blend Space | BS_ | | |\n| Blend Space 1D | BS_ | | |\n| Level Sequence | LS_ | | |\n| Morph Target | MT_ | | |\n| Paper Flipbook | PFB_ | | |\n| Rig | Rig_ | | |\n| Skeletal Mesh | SK_ | | |\n| Skeleton | SKEL_ | | |\n\n\u003ca name=\"anc-ai\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.3\"\u003e\u003c/a\u003e\n### 1.2.3 Artificial Intelligence\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| AI Controller | AIC_ | | |\n| Behavior Tree | BT_ | | |\n| Blackboard | BB_ | | |\n| Decorator | BTDecorator_ | | |\n| Service | BTService_ | | |\n| Task | BTTask_ | | |\n| Environment Query | EQS_ | | |\n| EnvQueryContext | EQS_ | Context | |\n\n\u003ca name=\"anc-bp\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.4\"\u003e\u003c/a\u003e\n### 1.2.4 Blueprints\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Blueprint | BP_ | | |\n| Blueprint Component | BP_ | Component | I.e. BP_InventoryComponent |\n| Blueprint Function Library | BPFL_ | | |\n| Blueprint Interface | BPI_ | | |\n| Blueprint Macro Library | BPML_ | | Do not use macro libraries if possible. |\n| Enumeration | E | | No underscore. |\n| Structure | F or S | | No underscore. |\n| Tutorial Blueprint | TBP_ | | |\n| Widget Blueprint | WBP_ | | |\n\n\u003ca name=\"anc-materials\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.5\"\u003e\u003c/a\u003e\n### 1.2.5 Materials\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------------- | ---------- | ---------- | -------------------------------- |\n| Material | M_ | | |\n| Material (Post Process) | PP_ | | |\n| Material Function | MF_ | | |\n| Material Instance | MI_ | | |\n| Material Parameter Collection | MPC_ | | |\n| Subsurface Profile | SP_ | | |\n| Physical Materials | PM_ | | |\n| Decal | M_, MI_ | _Decal | |\n\n\u003ca name=\"anc-textures\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.6\"\u003e\u003c/a\u003e\n### 1.2.6 Textures\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Texture | T_ | | |\n| Texture (Diffuse/Albedo/Base Color)| T_ | _D | |\n| Texture (Normal) | T_ | _N | |\n| Texture (Roughness) | T_ | _R | |\n| Texture (Alpha/Opacity) | T_ | _A | |\n| Texture (Ambient Occlusion) | T_ | _O | |\n| Texture (Bump) | T_ | _B | |\n| Texture (Emissive) | T_ | _E | |\n| Texture (Mask) | T_ | _M | |\n| Texture (Specular) | T_ | _S | |\n| Texture (Metallic) | T_ | _M | |\n| Texture (Packed) | T_ | _* | See notes below about [packing](#anc-textures-packing). |\n| Texture Cube | TC_ | | |\n| Media Texture | MT_ | | |\n| Render Target | RT_ | | |\n| Cube Render Target | RTC_ | | |\n| Texture Light Profile | TLP | | |\n\n\u003ca name=\"anc-textures-packing\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.6.1\"\u003e\u003c/a\u003e\n#### 1.2.6.1 Texture Packing\nIt is common practice to pack multiple layers of texture data into one texture. An example of this is packing Emissive, Roughness, Ambient Occlusion together as the Red, Green, and Blue channels of a texture respectively. To determine the suffix, simply stack the given suffix letters from above together, e.g. `_ERO`.\n\n\u003e It is generally acceptable to include an Alpha/Opacity layer in your Diffuse/Albedo's alpha channel and as this is common practice, adding `A` to the `_D` suffix is optional.\n\nPacking 4 channels of data into a texture (RGBA) is not recommended except for an Alpha/Opacity mask in the Diffuse/Albedo's alpha channel as a texture with an alpha channel incurs more overhead than one without.\n\n\u003ca name=\"anc-misc\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.7\"\u003e\u003c/a\u003e\n### 1.2.7 Miscellaneous\n\n| Asset Type | Prefix | Suffix | Notes |\n| -------------------------- | ---------- | ---------- | -------------------------------- |\n| Animated Vector Field | VFA_ | | |\n| Camera Anim | CA_ | | |\n| Color Curve | Curve_ | _Color | |\n| Curve Table | Curve_ | _Table | |\n| Data Asset | *_ | | Prefix should be based on class. |\n| Data Table | DT_ | | |\n| Float Curve | Curve_ | _Float | |\n| Foliage Type | FT_ | | |\n| Force Feedback Effect | FFE_ | | |\n| Landscape Grass Type | LG_ | | |\n| Landscape Layer | LL_ | | |\n| Matinee Data | Matinee_ | | |\n| Media Player | MP_ | | |\n| File Media Source | FMS_ | | |\n| Object Library | OL_ | | |\n| Redirector | | | These should be fixed up ASAP. |\n| Sprite Sheet | SS_ | | |\n| Static Vector Field | VF_ | | |\n| Substance Graph Instance | SGI_ | | |\n| Substance Instance Factory | SIF_ | | |\n| Touch Interface Setup | TI_ | | |\n| Vector Curve | Curve_ | _Vector | |\n\n\u003ca name=\"anc-paper2d\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.8\"\u003e\u003c/a\u003e\n### 1.2.8 Paper 2D\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Paper Flipbook | PFB_ | | |\n| Sprite | SPR_ | | |\n| Sprite Atlas Group | SPRG_ | | |\n| Tile Map | TM_ | | |\n| Tile Set | TS_ | | |\n\n\u003ca name=\"anc-physics\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.9\"\u003e\u003c/a\u003e\n### 1.2.9 Physics\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Physical Material | PM_ | | |\n| Physics Asset | PHYS_ | | |\n| Destructible Mesh | DM_ | | |\n\n\u003ca name=\"anc-sounds\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.10\"\u003e\u003c/a\u003e\n### 1.2.10 Sounds\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Dialogue Voice | DV_ | | |\n| Dialogue Wave | DW_ | | |\n| Media Sound Wave | MSW_ | | |\n| Reverb Effect | Reverb_ | | |\n| Sound Attenuation | ATT_ | | |\n| Sound Class | | | No prefix/suffix. Should be put in a folder called SoundClasses |\n| Sound Concurrency | | _SC | Should be named after a SoundClass |\n| Sound Cue | A_ | _Cue | |\n| Sound Mix | Mix_ | | |\n| Sound Wave | A_ | | |\n\n\u003ca name=\"anc-ui\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.11\"\u003e\u003c/a\u003e\n### 1.2.11 User Interface\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Font | Font_ | | |\n| Slate Brush | Brush_ | | |\n| Slate Widget Style | Style_ | | |\n| Widget Blueprint | WBP_ | | |\n\n\u003ca name=\"anc-effects\"\u003e\u003c/a\u003e\n\u003ca name=\"1.2.12\"\u003e\u003c/a\u003e\n### 1.2.12 Effects\n\n| Asset Type | Prefix | Suffix | Notes |\n| ----------------------- | ---------- | ---------- | -------------------------------- |\n| Particle System | PS_ | | |\n| Material (Post Process) | PP_ | | |\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\u003ca name=\"2\"\u003e\u003c/a\u003e\n\u003ca name=\"structure\"\u003e\u003c/a\u003e\n## 2. Content Directory Structure\n\nEqually important as asset names, the directory structure style of a project should be considered law. Asset naming conventions and content directory structure go hand in hand, and a violation of either causes unneeded chaos.\n\nThere are multiple ways to lay out the content of a UE4 project. In this style, we will be using a structure that relies more on filtering and search abilities of the Content Browser for those working with assets to find assets of a specific type instead of another common structure that groups asset types with folders.\n\n\u003e If you are using the prefix [naming convention](#1.2) above, using folders to contain assets of similar types such as `Meshes`, `Textures`, and `Materials` is a redundant practice as asset types are already both sorted by prefix as well as able to be filtered in the content browser.\n\n\u003ca name=\"2e1\"\u003e\u003ca\u003e\n### 2e1 Example Project Content Structure\n\u003cpre\u003e\n|-- Content\n |-- \u003ca href=\"#2.2\"\u003eGenericShooter\u003c/a\u003e\n |-- Art\n | |-- Industrial\n | | |-- Ambient\n | | |-- Machinery\n | | |-- Pipes\n | |-- Nature\n | | |-- Ambient\n | | |-- Foliage\n | | |-- Rocks\n | | |-- Trees\n | |-- Office\n |-- Characters\n | |-- Bob\n | |-- Common\n | | |-- \u003ca href=\"#2.7\"\u003eAnimations\u003c/a\u003e\n | | |-- Audio\n | |-- Jack\n | |-- Steve\n | |-- \u003ca href=\"#2.1.3\"\u003eZoe\u003c/a\u003e\n |-- \u003ca href=\"#2.5\"\u003eCore\u003c/a\u003e\n | |-- Characters\n | |-- Engine\n | |-- \u003ca href=\"#2.1.2\"\u003eGameModes\u003c/a\u003e\n | |-- Interactables\n | |-- Pickups\n | |-- Weapons\n |-- Effects\n | |-- Electrical\n | |-- Fire\n | |-- Weather\n |-- \u003ca href=\"#2.4\"\u003eMaps\u003c/a\u003e\n | |-- Campaign1\n | |-- Campaign2\n |-- \u003ca href=\"#2.8\"\u003eMaterialLibrary\u003c/a\u003e\n | |-- Debug\n | |-- Metal\n | |-- Paint\n | |-- Utility\n | |-- Weathering\n |-- Placeables\n | |-- Pickups\n |-- Weapons\n |-- Common\n |-- Pistols\n | |-- DesertEagle\n | |-- RocketPistol\n |-- Rifles\n\u003c/pre\u003e\n\nThe reasons for this structure are listed in the following sub-sections.\n\n\u003ca name=\"2.1\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-folder-names\"\u003e\u003ca\u003e\n### 2.1 Folder Names\n\nThese are common rules for naming any folder in the content structure.\n\n\u003ca name=\"2.1.1\"\u003e\u003c/a\u003e\n#### 2.1.1 Always Use PascalCase[\u003csup\u003e*\u003c/sup\u003e](#terms-cases)\n\nPascalCase refers to starting a name with a capital letter and then instead of using spaces, every following word also starts with a capital letter. For example, `DesertEagle`, `RocketPistol`, and `ASeriesOfWords`.\n\nSee [Cases](#terms-cases).\n\n\u003ca name=\"2.1.2\"\u003e\u003c/a\u003e\n#### 2.1.2 Never Use Spaces\n\nRe-enforcing [2.1.1](#2.1.1), never use spaces. Spaces can cause various engineering tools and batch processes to fail. Ideally, your project's root also contains no spaces and is located somewhere such as `D:\\Project` instead of `C:\\Users\\My Name\\My Documents\\Unreal Projects`.\n\n\u003ca name=\"2.1.3\"\u003e\u003c/a\u003e\n#### 2.1.3 Never Use Unicode Characters And Other Symbols\n\nIf one of your game characters is named 'Zoë', its folder name should be `Zoe`. Unicode characters can be worse than [Spaces](#2.1.2) for engineering tool and some parts of UE4 don't support Unicode characters in paths either.\n\nRelated to this, if your project has [unexplained issues](https://answers.unrealengine.com/questions/101207/undefined.html) and your computer's user name has a Unicode character (i.e. your name is `Zoë`), any project located in your `My Documents` folder will suffer from this issue. Often simply moving your project to something like `D:\\Project` will fix these mysterious issues.\n\nUsing other characters outside `a-z`, `A-Z`, and `0-9` such as `@`, `-`, `_`, `,`, `*`, and `#` can also lead to unexpected and hard to track issues on other platforms, source control, and weaker engineering tools.\n\n\u003ca name=\"2.2\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-top-level\"\u003e\u003ca\u003e\n### 2.2 Use A Top Level Folder For Project Specific Assets\n\nAll of a project's assets should exist in a folder named after the project. For example, if your project is named 'Generic Shooter', _all_ of it's content should exist in `Content/GenericShooter`.\n\n\u003e The `Developers` folder is not for assets that your project relies on and therefore is not project specific. See [Developer Folders](#2.3) for details about this.\n\nThere are multiple reasons for this approach.\n\n\u003ca name=\"2.2.1\"\u003e\u003c/a\u003e\n#### 2.2.1 No Global Assets\n\nOften in code style guides it is written that you should not pollute the global namespace and this follows the same principle. When assets are allowed to exist outside of a project folder, it often becomes much harder to enforce a strict structure layout as assets not in a folder encourages the bad behavior of not having to organize assets.\n\nEvery asset should have a purpose, otherwise it does not belong in a project. If an asset is an experimental test and shouldn't be used by the project it should be put in a [`Developer`](#2.3) folder.\n\n\u003ca name=\"2.2.2\"\u003e\u003c/a\u003e\n#### 2.2.2 Reduce Migration Conflicts\n\nWhen working on multiple projects it is common for a team to copy assets from one project to another if they have made something useful for both. When this occurs, the easiest way to perform the copy is to use the Content Browser's Migrate functionality as it will copy over not just the selected asset but all of its dependencies.\n\nThese dependencies are what can easily get you into trouble. If two project's assets do not have a top level folder and they happen to have similarly named or already previously migrated assets, a new migration can accidentally wipe any changes to the existing assets.\n\nThis is also the primary reason why Epic's Marketplace staff enforces the same policy for submitted assets.\n\nAfter a migration, safe merging of assets can be done using the 'Replace References' tool in the content browser with the added clarity of assets not belonging to a project's top level folder are clearly pending a merge. Once assets are merged and fully migrated, there shouldn't be another top level folder in your Content tree. This method is _100%_ guaranteed to make any migrations that occur completely safe.\n\n\u003ca name=\"2.2.2e1\"\u003e\u003c/a\u003e\n##### 2.2.2e1 Master Material Example\n\nFor example, say you created a master material in one project that you would like to use in another project so you migrated that asset over. If this asset is not in a top level folder, it may have a name like `Content/MaterialLibrary/M_Master`. If the target project doesn't have a master material already, this should work without issue.\n\nAs work on one or both projects progress, their respective master materials may change to be tailored for their specific projects due to the course of normal development.\n\nThe issue comes when, for example, an artist for one project created a nice generic modular set of static meshes and someone wants to include that set of static meshes in the second project. If the artist who created the assets used material instances based on `Content/MaterialLibrary/M_Master` as they're instructed to, when a migration is performed there is a great chance of conflict for the previously migrated `Content/MaterialLibrary/M_Master` asset.\n\nThis issue can be hard to predict and hard to account for. The person migrating the static meshes may not be the same person who is familiar with the development of both project's master material, and they may not be even aware that the static meshes in question rely on material instances which then rely on the master material. The Migrate tool requires the entire chain of dependencies to work however, and so it will be forced to grab `Content/MaterialLibrary/M_Master` when it copies these assets to the other project and it will overwrite the existing asset.\n\nIt is at this point where if the master materials for both projects are incompatible in _any way_, you risk breaking possibly the entire material library for a project as well as any other dependencies that may have already been migrated, simply because assets were not stored in a top level folder. The simple migration of static meshes now becomes a very ugly task.\n\n\u003ca name=\"2.2.3\"\u003e\u003c/a\u003e\n#### 2.2.3 Samples, Templates, and Marketplace Content Are Risk-Free\n\nAn extension to [2.2.2](#2.2.2), if a team member decides to add sample content, template files, or assets they bought from the marketplace, it is guaranteed, as long your project's top-level folder is uniquely named,that these new assets will not interfere with your project.\n\nYou can not trust marketplace content to fully conform to the [top level folder rule](#2.2). There exists many assets that have the majority of their content in a top level folder but also have possibly modified Epic sample content as well as level files polluting the global `Content` folder.\n\nWhen adhering to [2.2](#2.2), the worst marketplace conflict you can have is if two marketplace assets both have the same Epic sample content. If all your assets are in a project specific folder, including sample content you may have moved into your folder, your project will never break.\n\n\u003ca name=\"2.2.4\"\u003e\u003c/a\u003e\n#### 2.2.4 DLC, Sub-Projects, and Patches Are Easily Maintained\n\nIf your project plans to release DLC or has multiple sub-projects associated with it that may either be migrated out or simply not cooked in a build, assets relating to these projects should have their own separate top level content folder. This make cooking DLC separate from main project content far easier. Sub-projects can also be migrated in and out with minimal effort. If you need to change a material of an asset or add some very specific asset override behavior in a patch, you can easily put these changes in a patch folder and work safely without the chance of breaking the core project.\n\n\u003ca name=\"2.3\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-developers\"\u003e\u003c/a\u003e\n### 2.3 Use Developers Folder For Local Testing\n\nDuring a project's development, it is very common for team members to have a sort of 'sandbox' where they can experiment freely without risking the core project. Because this work may be ongoing, these team members may wish to put their assets on a project's source control server. Not all teams require use of Developer folders, but ones that do use them often run into a common problem with assets submitted to source control.\n\nIt is very easy for a team member to accidentally use assets that are not ready for use, which will cause issues once those assets are removed. For example, an artist may be iterating on a modular set of static meshes and still working on getting their sizing and grid snapping correct. If a world builder sees these assets in the main project folder, they might use them all over a level not knowing they could be subject to incredible change and/or removal. This causes massive amounts of re-working for everyone on the team to resolve.\n\nIf these modular assets were placed in a Developer folder, the world builder should never have had a reason to use them and the whole issue would never happen. The Content Browser has specific View Options that will hide Developer folders (they are hidden by default) making it impossible to accidentally use Developer assets under normal use.\n\nOnce the assets are ready for use, an artist simply has to move the assets into the project specific folder and fix up redirectors. This is essentially 'promoting' the assets from experimental to production.\n\n\u003ca name=\"2.4\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-maps\"\u003e\u003c/a\u003e\n### 2.4 All Map[\u003csup\u003e*\u003c/sup\u003e](#terms-level-map) Files Belong In A Folder Called Maps\n\nMap files are incredibly special and it is common for every project to have its own map naming system, especially if they work with sub-levels or streaming levels. No matter what system of map organization is in place for the specific project, all levels should belong in `/Content/Project/Maps`.\n\nBeing able to tell someone to open a specific map without having to explain where it is is a great time saver and general 'quality of life' improvement. It is common for levels to be within sub-folders of `Maps`, such as `Maps/Campaign1/` or `Maps/Arenas`, but the most important thing here is that they all exist within `/Content/Project/Maps`.\n\nThis also simplifies the job of cooking for engineers. Wrangling levels for a build process can be extremely frustrating if they have to dig through arbitrary folders for them. If a team's maps are all in one place, it is much harder to accidentally not cook a map in a build. It also simplifies lighting build scripts as well as QA processes.\n\n\u003ca name=\"2.5\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-core\"\u003e\u003c/a\u003e\n### 2.5 Use A `Core` Folder For Critical Blueprints And Other Assets\n\nUse `/Content/Project/Core` folder for assets that are absolutely fundamental to a project's workings. For example, base `GameMode`, `Character`, `PlayerController`, `GameState`, `PlayerState`, and related Blueprints should live here.\n\nThis creates a very clear \"don't touch these\" message for other team members. Non-engineers should have very little reason to enter the `Core` folder. Following good code structure style, designers should be making their gameplay tweaks in child classes that expose functionality. World builders should be using prefab Blueprints in designated folders instead of potentially abusing base classes.\n\nFor example, if your project requires pickups that can be placed in a level, there should exist a base Pickup class in `Core/Pickups` that defines base behavior for a pickup. Specific pickups such as a Health or Ammo should exist in a folder such as `/Content/Project/Placeables/Pickups/`. Game designers can define and tweak pickups in this folder however they please, but they should not touch `Core/Pickups` as they may unintentionally break pickups project-wide.\n\n\u003ca name=\"2.6\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-assettypes\"\u003e\u003c/a\u003e\n### 2.6 Do Not Create Folders Called `Assets` or `AssetTypes`\n\n\u003ca name=\"2.6.1\"\u003e\u003c/a\u003e\n#### 2.6.1 Creating a folder named `Assets` is redundant\n\nAll assets are assets.\n\n\u003ca name=\"2.6.2\"\u003e\u003c/a\u003e\n#### 2.6.2 Creating a folder named `Meshes`, `Textures`, or `Materials` is redundant\n\nAll asset names are named with their asset type in mind. These folders offer only redundant information and the use of these folders can easily be replaced with the robust and easy to use filtering system the Content Browser provides.\n\nWant to view only static mesh in `Environment/Rocks/`? Simply turn on the Static Mesh filter. If all assets are named correctly, they will also be sorted in alphabetical order regardless of prefixes. Want to view both static meshes and skeletal meshes? Simply turn on both filters. This eliminates the need to potentially have to `Control-Click` select two folders in the Content Browser's tree view.\n\n\u003e This also extends the full path name of an asset for very little benefit. The `S_` prefix for a static mesh is only two characters, whereas `Meshes/` is seven characters.\n\nNot doing this also prevents the inevitability of someone putting a static mesh or a texture in a `Materials` folder.\n\n\u003ca name=\"2.7\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-large-sets\"\u003e\u003c/a\u003e\n### 2.7 Very Large Asset Sets Get Their Own Folder Layout\n\nThis can be seen as a pseudo-exception to [2.6](#2.6).\n\nThere are certain asset types that have a huge volume of related files where each asset has a unique purpose. The two most common are Animation and Audio assets. If you find yourself having 15+ of these assets that belong together, they should be together.\n\nFor example, animations that are shared across multiple characters should lay in `Characters/Common/Animations` and may have sub-folders such as `Locomotion` or `Cinematic`.\n\n\u003e This does not apply to assets like textures and materials. It is common for a `Rocks` folder to have a large amount of textures if there are a large amount of rocks, however these textures are generally only related to a few specific rocks and should be named appropriately. Even if these textures are part of a [Material Library](#2.8).\n\n\u003ca name=\"2.8\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-material-library\"\u003e\u003c/a\u003e\n### 2.8 `MaterialLibrary`\n\nIf your project makes use of master materials, layered materials, or any form of reusable materials or textures that do not belong to any subset of assets, these assets should be located in `Content/Project/MaterialLibrary`.\n\nThis way all 'global' materials have a place to live and are easily located.\n\n\u003e This also makes it incredibly easy to enforce a 'use material instances only' policy within a project. If all artists and assets should be using material instances, then the only regular material assets that should exist are within this folder. You can easily verify this by searching for base materials in any folder that isn't the `MaterialLibrary`.\n\nThe `MaterialLibrary` doesn't have to consist of purely materials. Shared utility textures, material functions, and other things of this nature should be stored here as well within folders that designate their intended purpose. For example, generic noise textures should be located in `MaterialLibrary/Utility`.\n\nAny testing or debug materials should be within `MaterialLibrary/Debug`. This allows debug materials to be easily stripped from a project before shipping and makes it incredibly apparent if production assets are using them if reference errors are shown.\n\n\u003ca name=\"2.9\"\u003e\u003c/a\u003e\n\u003ca name=\"structure-no-empty-folders\"\u003e\u003c/a\u003e\n### 2.9 No Empty Folders\n\nThere simply shouldn't be any empty folders. They clutter the content browser.\n\nIf you find that the content browser has an empty folder you can't delete, you should perform the following:\n1. Be sure you're using source control.\n1. Immediately run Fix Up Redirectors on your project.\n1. Navigate to the folder on-disk and delete the assets inside.\n1. Close the editor.\n1. Make sure your source control state is in sync (i.e. if using Perforce, run a Reconcile Offline Work on your content directory)\n1. Open the editor. Confirm everything still works as expected. If it doesn't, revert, figure out what went wrong, and try again.\n1. Ensure the folder is now gone.\n1. Submit changes to source control.\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\n\u003ca name=\"3\"\u003e\u003c/a\u003e\n\u003ca name=\"bp\"\u003e\u003c/a\u003e\n## 3. Blueprints\n\nThis section will focus on Blueprint classes and their internals. When possible, style rules conform to [Epic's Coding Standard](https://docs.unrealengine.com/latest/INT/Programming/Development/CodingStandard).\n\nRemember: Blueprinting badly bears blunders, beware! (Phrase by [KorkuVeren](http://github.com/KorkuVeren))\n\n\u003ca name=\"3.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-compiling\"\u003e\u003c/a\u003e\n### 3.1 Compiling\n\nAll blueprints should compile with zero warnings and zero errors. You should fix blueprint warnings and errors immediately as they can quickly cascade into very scary unexpected behavior.\n\nDo *not* submit broken blueprints to source control. If you must store them on source control, shelve them instead.\n\nBroken blueprints can cause problems that manifest in other ways, such as broken references, unexpected behavior, cooking failures, and frequent unneeded recompilation. A broken blueprint has the power to break your entire game.\n\n\u003ca name=\"3.2\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars\"\u003e\u003c/a\u003e\n### 3.2 Variables\n\nThe words `variable` and `property` may be used interchangeably.\n\n\u003ca name=\"3.2.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-var-naming\"\u003e\u003c/a\u003e\n#### 3.2.1 Naming\n\n\u003ca name=\"3.2.1.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-var-naming-nouns\"\u003e\u003c/a\u003e\n##### 3.2.1.1 Nouns\n\nAll non-boolean variable names must be clear, unambiguous, and descriptive nouns.\n\n\u003ca name=\"3.2.1.2\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-var-naming-case\"\u003e\u003c/a\u003e\n##### 3.2.1.2 PascalCase\n\nAll non-boolean variables should be in the form of [PascalCase](#terms-cases).\n\n\u003ca name=\"3.2.1.2e\"\u003e\u003c/a\u003e\n###### 3.2.1.2e Examples\n\n* `Score`\n* `Kills`\n* `TargetPlayer`\n* `Range`\n* `CrosshairColor`\n* `AbilityID`\n\n\u003ca name=\"3.2.1.3\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-var-bool-prefix\"\u003e\u003c/a\u003e\n##### 3.2.1.3 Boolean `b` Prefix\n\nAll booleans should be named in PascalCase but prefixed with a lowercase `b`.\n\nExample: Use `bDead` and `bEvil`, **not** `Dead` and `Evil`.\n\nUE4 Blueprint editors know not to include the `b` in user-friendly displays of the variable.\n\n\u003ca name=\"3.2.1.4\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-var-bool-names\"\u003e\u003c/a\u003e\n##### 3.2.1.4 Boolean Names\n\n\u003ca name=\"3.2.1.4.1\"\u003e\u003c/a\u003e\n###### 3.2.1.4.1 General And Independent State Information\n\nAll booleans should be named as descriptive adjectives when possible if representing general information. Do not include words that phrase the variable as a question, such as `Is`. This is reserved for functions.\n\nExample: Use `bDead` and `bHostile` **not** `bIsDead` and `bIsHostile`.\n\nTry to not use verbs such as `bRunning`. Verbs tend to lead to complex states.\n\n\u003ca name=\"3.2.1.4.2\"\u003e\u003c/a\u003e\n###### 3.2.1.4.2 Complex States\n\nDo not to use booleans to represent complex and/or dependent states. This makes state adding and removing complex and no longer easily readable. Use an enumeration instead.\n\nExample: When defining a weapon, do **not** use `bReloading` and `bEquipping` if a weapon can't be both reloading and equipping. Define an enumeration named `EWeaponState` and use a variable with this type named `WeaponState` instead. This makes it far easier to add new states to weapons.\n\nExample: Do **not** use `bRunning` if you also need `bWalking` or `bSprinting`. This should be defined as an enumeration with clearly defined state names.\n\n\u003ca name=\"3.2.1.5\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-naming-context\"\u003e\u003c/a\u003e\n##### 3.2.1.5 Considered Context\n\nAll variable names must not be redundant with their context as all variable references in Blueprint will always have context.\n\n\u003ca name=\"3.2.1.5e\"\u003e\u003c/a\u003e\n###### 3.2.1.5e Examples\n\nConsider a Blueprint called `BP_PlayerCharacter`.\n\n**Bad**\n\n* `PlayerScore`\n* `PlayerKills`\n* `MyTargetPlayer`\n* `MyCharacterName`\n* `CharacterSkills`\n* `ChosenCharacterSkin`\n\nAll of these variables are named redundantly. It is implied that the variable is representative of the `BP_PlayerCharacter` it belongs to because it is `BP_PlayerCharacter` that is defining these variables.\n\n**Good**\n\n* `Score`\n* `Kills`\n* `TargetPlayer`\n* `Name`\n* `Skills`\n* `Skin`\n\n\u003ca name=\"3.2.1.6\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-naming-atomic\"\u003e\u003c/a\u003e\n##### 3.2.1.6 Do _Not_ Include Atomic Type Names\n\nAtomic or primitive variables are variables that represent data in their simplest form, such as booleans, integers, floats, and enumerations.\n\nStrings and vectors are considered atomic in terms of style when working with Blueprints, however they are technically not atomic.\n\n\u003e While vectors consist of three floats, vectors are often able to be manipulated as a whole, same with rotators.\n\n\u003e Do _not_ consider Text variables as atomic, they are secretly hiding localization functionality. The atomic type of a string of characters is `String`, not `Text`.\n\nAtomic variables should not have their type name in their name.\n\nExample: Use `Score`, `Kills`, and `Description` **not** `ScoreFloat`, `FloatKills`, `DescriptionString`.\n\nThe only exception to this rule is when a variable represents 'a number of' something to be counted _and_ when using a name without a variable type is not easy to read.\n\nExample: A fence generator needs to generate X number of posts. Store X in `NumPosts` or `PostsCount` instead of `Posts` as `Posts` may potentially read as an Array of a variable type named `Post`.\n\n\u003ca name=\"3.2.1.7\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-naming-complex\"\u003e\u003c/a\u003e\n##### 3.2.1.7 Do Include Non-Atomic Type Names\n\nNon-atomic or complex variables are variables that represent data as a collection of atomic variables. Structs, Classes, Interfaces, and primitives with hidden behavior such as `Text` and `Name` all qualify under this rule.\n\n\u003e While an Array of an atomic variable type is a list of variables, Arrays do not change the 'atomicness' of a variable type.\n\nThese variables should include their type name while still considering their context.\n\nIf a class owns an instance of a complex variable, i.e. if a `BP_PlayerCharacter` owns a `BP_Hat`, it should be stored as the variable type as without any name modifications.\n\nExample: Use `Hat`, `Flag`, and `Ability` **not** `MyHat`, `MyFlag`, and `PlayerAbility`.\n\nIf a class does not own the value a complex variable represents, you should use a noun along with the variable type.\n\nExample: If a `BP_Turret` has the ability to target a `BP_PlayerCharacter`, it should store its target as `TargetPlayer` as when in the context of `BP_Turret` it should be clear that it is a reference to another complex variable type that it does not own.\n\n\n\u003ca name=\"3.2.1.8\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-naming-arrays\"\u003e\u003c/a\u003e\n##### 3.2.1.8 Arrays\n\nArrays follow the same naming rules as above, but should be named as a plural noun.\n\nExample: Use `Targets`, `Hats`, and `EnemyPlayers`, **not** `TargetList`, `HatArray`, `EnemyPlayerArray`.\n\n\n\u003ca name=\"3.2.2\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-editable\"\u003e\u003c/a\u003e\n#### 3.2.2 Editable Variables\n\nAll variables that are safe to change the value of in order to configure behavior of a blueprint should be marked as `Editable`.\n\nConversely, all variables that are not safe to change or should not be exposed to designers should _not_ be marked as editable, unless for engineering reasons the variable must be marked as `Expose On Spawn`.\n\nDo not arbitrarily mark variables as `Editable`.\n\n\u003ca name=\"3.2.2.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-editable-tooltips\"\u003e\u003c/a\u003e\n##### 3.2.2.1 Tooltips\n\nAll `Editable` variables, including those marked editable just so they can be marked as `Expose On Spawn`, should have a description in their `Tooltip` fields that explains how changing this value affects the behavior of the blueprint.\n\n\u003ca name=\"3.2.2.2\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-editable-ranges\"\u003e\u003c/a\u003e\n##### 3.2.2.2 Slider And Value Ranges\n\nAll `Editable` variables should make use of slider and value ranges if there is ever a value that a variable should _not_ be set to.\n\nExample: A blueprint that generates fence posts might have an editable variable named `PostsCount` and a value of -1 would not make any sense. Use the range fields to mark 0 as a minimum.\n\nIf an editable variable is used in a Construction Script, it should have a reasonable Slider Range defined so that someone can not accidentally assign it a large value that could crash the editor.\n\nA Value Range only needs to be defined if the bounds of a value are known. While a Slider Range prevents accidental large number inputs, an undefined Value Range allows a user to specify a value outside the Slider Range that may be considered 'dangerous' but still valid.\n\n\u003ca name=\"3.2.3\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-categories\"\u003e\u003c/a\u003e\n#### 3.2.3 Categories\n\nIf a class has only a small number of variables, categories are not required.\n\nIf a class has a moderate amount of variables (5-10), all `Editable` variables should have a non-default category assigned. A common category is `Config`.\n\nIf a class has a large amount of variables, all `Editable` variables should be categorized into sub-categories using the category `Config` as the base category. Non-editable variables should be categorized into descriptive categories describing their usage.\n\n\u003e You can define sub-categories by using the pipe character `|`, i.e. `Config | Animations`.\n\nExample: A weapon class set of variables might be organized as:\n\n |-- Config\n | |-- Animations\n | |-- Effects\n | |-- Audio\n | |-- Recoil\n | |-- Timings\n |-- Animations\n |-- State\n |-- Visuals\n\n\u003ca name=\"3.2.4\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-access\"\u003e\u003c/a\u003e\n#### 3.2.4 Variable Access Level\n\nIn C++, variables have a concept of access level. Public means any code outside the class can access the variable. Protected means only the class and any child classes can access this variable internally. Private means only this class and no child classes can access this variable.\n\nBlueprints do not have a defined concept of protected access currently.\n\nTreat `Editable` variables as public variables. Treat non-editable variables as protected variables.\n\n\u003ca name=\"3.2.4.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-access-private\"\u003e\u003c/a\u003e\n##### 3.2.4.1 Private Variables\n\nUnless it is known that a variable should only be accessed within the class it is defined and never a child class, do not mark variables as private. Until variables are able to be marked `protected`, reserve private for when you absolutely know you want to restrict child class usage.\n\n\u003ca name=\"3.2.5\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-advanced\"\u003e\u003c/a\u003e\n#### 3.2.5 Advanced Display\n\nIf a variable should be editable but often untouched, mark it as `Advanced Display`. This makes the variable hidden unless the advanced display arrow is clicked.\n\nTo find the `Advanced Display` option, it is listed as an advanced displayed variable in the variable details list.\n\n\u003ca name=\"3.2.6\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-transient\"\u003e\u003c/a\u003e\n#### 3.2.6 Transient Variables\n\nTransient variables are variables that do not need to have their value saved and loaded and have an initial value of zero or null. This is useful for references to other objects and actors who's value isn't known until run-time. This prevents the editor from ever saving a reference to it, and speeds up saving and loading of the blueprint class.\n\nBecause of this, all transient variables should always be initialized as zero or null. To do otherwise would result in hard to debug errors.\n\n\u003ca name=\"3.2.7\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-vars-config\"\u003e\u003c/a\u003e\n#### 3.2.8 Config Variables\n\nDo not use the `Config Variable` flag. This makes it harder for designers to control blueprint behavior. Config variables should only be used in C++ for rarely changed variables. Think of them as `Advanced Advanced Display` variables.\n\n\u003ca name=\"3.3\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-functions\"\u003e\u003c/a\u003e\n### 3.3 Functions, Events, and Event Dispatchers\n\nThis section describes how you should author functions, events, and event dispatchers. Everything that applies to functions also applies to events, unless otherwise noted.\n\n\u003ca name=\"3.3.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-funcs-naming\"\u003e\u003c/a\u003e\n#### 3.3.1 Function Naming\n\nThe naming of functions, events, and event dispatchers is critically important. Based on the name alone, certain assumptions can be made about functions. For example:\n\n* Is it a pure function?\n* Is it fetching state information?\n* Is it a handler?\n* Is it an RPC?\n* What is its purpose?\n\nThese questions and more can all be answered when functions are named appropriately.\n\n\u003ca name=\"3.3.1.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-funcs-naming-verbs\"\u003e\u003c/a\u003e\n#### 3.3.1.1 All Functions Should Be Verbs\n\nAll functions and events perform some form of action, whether its getting info, calculating data, or causing something to explode. Therefore, all functions should all start with verbs. They should be worded in the present tense whenever possible. They should also have some context as to what they are doing.\n\n`OnRep` functions, event handlers, and event dispatchers are an exception to this rule.\n\nGood examples:\n\n* `Fire` - Good example if in a Character / Weapon class, as it has context. Bad if in a Barrel / Grass / any ambiguous class.\n* `Jump` - Good example if in a Character class, otherwise, needs context.\n* `Explode`\n* `ReceiveMessage`\n* `SortPlayerArray`\n* `GetArmOffset`\n* `GetCoordinates`\n* `UpdateTransforms`\n* `EnableBigHeadMode`\n* `IsEnemy` - [\"Is\" is a verb.](http://writingexplained.org/is-is-a-verb)\n\nBad examples:\n\n* `Dead` - Is Dead? Will deaden?\n* `Rock`\n* `ProcessData` - Ambiguous, these words mean nothing.\n* `PlayerState` - Nouns are ambiguous.\n* `Color` - Verb with no context, or ambiguous noun.\n\n\u003ca name=\"3.3.1.2\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-funcs-naming-onrep\"\u003e\u003c/a\u003e\n#### 3.3.1.2 Property RepNotify Functions Always `OnRep_Variable`\n\nAll functions for replicated with notification variables should have the form `OnRep_Variable`. This is forced by the Blueprint editor. If you are writing a C++ `OnRep` function however, it should also follow this convention when exposing it to Blueprints.\n\n\u003ca name=\"3.3.1.3\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-funcs-naming-bool\"\u003e\u003c/a\u003e\n#### 3.3.1.3 Info Functions Returning Bool Should Ask Questions\n\nWhen writing a function that does not change the state of or modify any object and is purely for getting information, state, or computing a yes/no value, it should ask a question. This should also follow [the verb rule](#bp-funcs-naming-verbs).\n\nThis is extremely important as if a question is not asked, it may be assumed that the function performs an action and is returning whether that action succeeded.\n\nGood examples:\n\n* `IsDead`\n* `IsOnFire`\n* `IsAlive`\n* `IsSpeaking`\n* `IsHavingAnExistentialCrisis`\n* `IsVisible`\n* `HasWeapon` - [\"Has\" is a verb.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html)\n* `WasCharging` - [\"Was\" is past-tense of \"be\".](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html) Use \"was\" when referring to 'previous frame' or 'previous state'.\n* `CanReload` - [\"Can\" is a verb.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html)\n\nBad examples:\n\n* `Fire` - Is on fire? Will fire? Do fire?\n* `OnFire` - Can be confused with event dispatcher for firing.\n* `Dead` - Is dead? Will deaden?\n* `Visibility` - Is visible? Set visibility? A description of flying conditions?\n\n\u003ca name=\"3.3.1.4\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-funcs-naming-eventhandlers\"\u003e\u003c/a\u003e\n#### 3.3.1.4 Event Handlers and Dispatchers Should Start With `On`\n\nAny function that handles an event or dispatches an event should start with `On` and continue to follow [the verb rule](#bp-funcs-naming-verbs). The verb may move to the end however if past-tense reads better.\n\n[Collocations](http://dictionary.cambridge.org/us/grammar/british-grammar/about-words-clauses-and-sentences/collocation) of the word `On` are exempt from following the verb rule.\n\n`Handle` is not allowed. It is 'Unreal' to use `On` instead of `Handle`, while other frameworks may prefer to use `Handle` instead of `On`.\n\nGood examples:\n\n* `OnDeath` - Common collocation in games\n* `OnPickup`\n* `OnReceiveMessage`\n* `OnMessageRecieved`\n* `OnTargetChanged`\n* `OnClick`\n* `OnLeave`\n\nBad examples:\n\n* `OnData`\n* `OnTarget`\n* `HandleMessage`\n* `HandleDeath`\n\n\u003ca name=\"3.3.1.5\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-funcs-naming-rpcs\"\u003e\u003c/a\u003e\n#### 3.3.1.5 Remote Procedure Calls Should Be Prefixed With Target\n\nAny time an RPC is created, it should be prefixed with either `Server`, `Client`, or `Multicast`. No exceptions.\n\nAfter the prefix, follow all other rules regarding function naming.\n\nGood examples:\n\n* `ServerFireWeapon`\n* `ClientNotifyDeath`\n* `MulticastSpawnTracerEffect`\n\nBad examples:\n\n* `FireWeapon` - Does not indicate its an RPC of some kind.\n* `ServerClientBroadcast` - Confusing.\n* `AllNotifyDeath` - Use `Multicast`, never `All`.\n* `ClientWeapon` - No verb, ambiguous.\n\n\n\u003ca name=\"3.3.2\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-funcs-return\"\u003e\u003c/a\u003e\n#### 3.3.2 All Functions Must Have Return Nodes\n\nAll functions must have return nodes, no exceptions.\n\nReturn nodes explicitly note that a function has finished its execution. In a world where blueprints can be filled with `Sequence`, `ForLoopWithBreak`, and backwards reroute nodes, explicit execution flow is important for readability, maintenance, and easier debugging.\n\nThe Blueprint compiler is able to follow the flow of execution and will warn you if there is a branch of your code with an unhandled return or bad flow if you use return nodes.\n\nIn situations like where a programmer may add a pin to a Sequence node or add logic after a for loop completes but the loop iteration might return early, this can often result in an accidental error in code flow. The warnings the Blueprint compiler will alert everyone of these issues immediately.\n\n\u003ca name=\"3.3.3\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-funcs-node-limit\"\u003e\u003c/a\u003e\n#### 3.3.3 No Function Should Have More Than 50 Nodes\n\nSimply, no function should have more than 50 nodes. Any function this big should be broken down into smaller functions for readability and ease of maintenance.\n\nThe following nodes are not counted as they are deemed to not increase function complexity:\n\n* Comment\n* Route\n* Cast\n* Getting a Variable\n* Breaking a Struct\n* Function Entry\n* Self\n\n\u003ca name=\"3.3.4\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-funcs-description\"\u003e\u003c/a\u003e\n#### 3.3.4 All Public Functions Should Have A Description\n\nThis rule applies more to public facing or marketplace blueprints, so that others can more easily navigate and consume your blueprint API.\n\nSimply, any function that has an access specificer of Public should have its description filled out.\n\n\u003ca name=\"3.3.5\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-funcs-plugin-category\"\u003e\u003c/a\u003e\n#### 3.3.5 All Custom Static Plugin `BlueprintCallable` Functions Must Be Categorized By Plugin Name\n\nIf your project includes a plugin that defines `static` `BlueprintCallable` functions, they should have their category set to the plugin's name or a subset category of the plugin's name.\n\nFor example, `Zed Camera Interface` or `Zed Camera Interface | Image Capturing`.\n\n\u003ca name=\"3.4\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs\"\u003e\u003c/a\u003e\n### 3.4 Blueprint Graphs\n\nThis section covers things that apply to all Blueprint graphs.\n\n\u003ca name=\"3.4.1\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-spaghetti\"\u003e\u003c/a\u003e\n#### 3.4.1 No Spaghetti\n\nWires should have clear beginnings and ends. You should never have to mentally untangle wires to make sense of a graph. Many of the following sections are dedicated to reducing spaghetti.\n\n\u003ca name=\"3.4.2\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-align-wires\"\u003e\u003c/a\u003e\n#### 3.4.2 Align Wires Not Nodes\n\nAlways align wires, not nodes. You can't always control the size and pin location on a node, but you can always control the location of a node and thus control the wires. Straight wires provide clear linear flow. Wiggly wires wear wits wickedly. You can straighten wires by using the Straighten Connections command with BP nodes selected. Hotkey: Q\n\nGood example: The tops of the nodes are staggered to keep a perfectly straight white exec line.\n![Aligned By Wires](https://github.com/Allar/ue5-style-guide/blob/main/images/bp-graphs-align-wires-good.png?raw=true \"Aligned By Wires\")\n\nBad Example: The tops of the nodes are aligned creating a wiggly white exec line.\n![Bad](https://github.com/Allar/ue5-style-guide/blob/main/images/bp-graphs-align-wires-bad.png?raw=true \"Wiggly\")\n\nAcceptable Example: Certain nodes might not cooperate no matter how you use the alignment tools. In this situation, try to minimize the wiggle by bringing the node in closer.\n![Acceptable](https://github.com/Allar/ue5-style-guide/blob/main/images/bp-graphs-align-wires-acceptable.png?raw=true \"Acceptable\")\n\n\u003ca name=\"3.4.3\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-exec-first-class\"\u003e\u003c/a\u003e\n#### 3.4.3 White Exec Lines Are Top Priority\n\nIf you ever have to decide between straightening a linear white exec line or straightening data lines of some kind, always straighten the white exec line.\n\n\u003ca name=\"3.4.4\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-block-comments\"\u003e\u003c/a\u003e\n#### 3.4.4 Graphs Should Be Reasonably Commented\n\nBlocks of nodes should be wrapped in comments that describe their higher-level behavior. While every function should be well named so that each individual node is easily readable and understandable, groups of nodes contributing to a purpose should have their purpose described in a comment block. If a function does not have many blocks of nodes and its clear that the nodes are serving a direct purpose in the function's goal, then they do not need to be commented as the function name and description should suffice.\n\n\u003ca name=\"3.4.5\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-cast-error-handling\"\u003e\u003c/a\u003e\n#### 3.4.5 Graphs Should Handle Casting Errors Where Appropriate\n\nIf a function or event assumes that a cast always succeeds, it should appropriately report a failure in logic if the cast fails. This lets others know why something that is 'supposed to work' doesn't. A function should also attempt a graceful recover after a failed cast if it's known that the reference being casted could ever fail to be casted.\n\nThis does not mean every cast node should have its failure handled. In many cases, especially events regarding things like collisions, it is expected that execution flow terminates on a failed cast quietly.\n\n\u003ca name=\"3.4.6\"\u003e\u003c/a\u003e\n\u003ca name=\"bp-graphs-dangling-nodes\"\u003e\u003c/a\u003e\n#### 3.4.6 Graphs Should Not Have Any Dangling / Loose / Dead Nodes\n\nAll nodes in all blueprint graphs must have a purpose. You should not leave dangling blueprint nodes around that have no purpose or are not executed.\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\n\u003ca name=\"4\"\u003e\u003c/a\u003e\n\u003ca name=\"Static Meshes\"\u003e\u003c/a\u003e\n\u003ca name=\"s\"\u003e\u003c/a\u003e\n## 4. Static Meshes\n\nThis section will focus on Static Mesh assets and their internals.\n\n\u003ca name=\"4.1\"\u003e\u003c/a\u003e\n\u003ca name=\"s-uvs\"\u003e\u003c/a\u003e\n### 4.1 Static Mesh UVs\n\nIf Linter is reporting bad UVs and you can't seem to track it down, open the resulting `.log` file in your project's `Saved/Logs` folder for exact details as to why it's failing. I am hoping to include these messages in the Lint report in the future.\n\n\u003ca name=\"4.1.1\"\u003e\u003c/a\u003e\n\u003ca name=\"s-uvs-no-missing\"\u003e\u003c/a\u003e\n#### 4.1.1 All Meshes Must Have UVs\n\nPretty simple. All meshes, regardless how they are to be used, should not be missing UVs.\n\n\u003ca name=\"4.1.2\"\u003e\u003c/a\u003e\n\u003ca name=\"s-uvs-no-overlapping\"\u003e\u003c/a\u003e\n#### 4.1.2 All Meshes Must Not Have Overlapping UVs for Lightmaps\n\nPretty simple. All meshes, regardless how they are to be used, should have valid non-overlapping UVs.\n\n\u003ca name=\"4.2\"\u003e\u003c/a\u003e\n\u003ca name=\"s-lods\"\u003e\u003c/a\u003e\n### 4.2 LODs Should Be Set Up Correctly\n\nThis is a subjective check on a per-project basis, but as a general rule any mesh that can be seen at varying distances should have proper LODs.\n\n\u003ca name=\"4.3\"\u003e\u003c/a\u003e\n\u003ca name=\"s-modular-snapping\"\u003e\u003c/a\u003e\n### 4.3 Modular Socketless Assets Should Snap To The Grid Cleanly\n\nThis is a subjective check on a per-asset basis, however any modular socketless assets should snap together cleanly based on the project's grid settings.\n\nIt is up to the project whether to snap based on a power of 2 grid or on a base 10 grid. However if you are authoring modular socketless assets for the marketplace, Epic's requirement is that they snap cleanly when the grid is set to 10 units or bigger.\n\n\u003ca name=\"4.4\"\u003e\u003c/a\u003e\n\u003ca name=\"s-collision\"\u003e\u003c/a\u003e\n### 4.4 All Meshes Must Have Collision\n\nRegardless of whether an asset is going to be used for collision in a level, all meshes should have proper collision defined. This helps the engine with things such as bounds calculations, occlusion, and lighting. Collision should also be well-formed to the asset.\n\n\u003ca name=\"4.5\"\u003e\u003c/a\u003e\n\u003ca name=\"s-scaled\"\u003e\u003c/a\u003e\n### 4.5 All Meshes Should Be Scaled Correctly\n\nThis is a subjective check on a per-project basis, however all assets should be scaled correctly to their project. Level designers or blueprint authors should not have to tweak the scale of meshes to get them to confirm in the editor. Scaling meshes in the engine should be treated as a scale override, not a scale correction.\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\n\u003ca name=\"5\"\u003e\u003c/a\u003e\n\u003ca name=\"Niagara\"\u003e\u003c/a\u003e\n\u003ca name=\"ng\"\u003e\u003c/a\u003e\n## 5. Niagara\n\nThis section will focus on Niagara assets and their internals.\n\n\u003ca name=\"5.1\"\u003e\u003c/a\u003e\n\u003ca name=\"ng-rules\"\u003e\u003c/a\u003e\n### 5.1 No Spaces, Ever\n\nAs mentioned in [00.1 Forbidden Identifiers](#00), spaces and all white space characters are forbidden in identifiers. This is especially true for Niagara systems as it makes working with things significantly harder if not impossible when working with HLSL or other means of scripting within Niagara and trying to reference an identifier.\n\n(Original Contribution by [@dunenkoff](https://github.com/Allar/ue5-style-guide/issues/58))\n\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\n\u003ca name=\"6\"\u003e\u003c/a\u003e\n\u003ca name=\"Levels\"\u003e\u003c/a\u003e\n\u003ca name=\"levels\"\u003e\u003c/a\u003e\n## 6. Levels / Maps\n\n[See Terminology Note](#terms-level-map) regarding \"levels\" vs \"maps\".\n\nThis section will focus on Level assets and their internals.\n\n\u003ca name=\"6.1\"\u003e\u003c/a\u003e\n\u003ca name=\"levels-no-errors-or-warnings\"\u003e\u003c/a\u003e\n### 6.1 No Errors Or Warnings\n\nAll levels should load with zero errors or warnings. If a level loads with any errors or warnings, they should be fixed immediately to prevent cascading issues.\n\nYou can run a map check on an open level in the editor by using the console command \"map check\".\n\nPlease note: Linter is even more strict on this than the editor is currently, and will catch load errors that the editor will resolve on its own.\n\n\u003ca name=\"6.2\"\u003e\u003c/a\u003e\n\u003ca name=\"levels-lighting-should-be-built\"\u003e\u003c/a\u003e\n### 6.2 Lighting Should Be Built\n\nIt is normal during development for levels to occasionally not have lighting built. When doing a test/internal/shipping build or any build that is to be distributed however, lighting should always be built.\n\n\u003ca name=\"6.3\"\u003e\u003c/a\u003e\n\u003ca name=\"levels-no-visible-z-fighting\"\u003e\u003c/a\u003e\n### 6.3 No Player Visible Z Fighting\n\nLevels should not have any [z-fighting](https://en.wikipedia.org/wiki/Z-fighting) in all areas visible to the player.\n\n\u003ca name=\"6.4\"\u003e\u003c/a\u003e\n\u003ca name=\"levels-mp-rules\"\u003e\u003c/a\u003e\n### 6.4 Marketplace Specific Rules\n\nIf a project is to be sold on the UE4 Marketplace, it must follow these rules.\n\n\u003ca name=\"6.4.1\"\u003e\u003c/a\u003e\n\u003ca name=\"levels-mp-rules-overview\"\u003e\u003c/a\u003e\n#### 6.4.1 Overview Level\n\nIf your project contains assets that should be visualized or demoed, you must have a map within your project that contains the name \"Overview\".\n\nThis overview map, if it is visualizing assets, should be set up according to [Epic's guidelines](http://help.epicgames.com/customer/en/portal/articles/2592186-marketplace-submission-guidelines-preparing-your-assets#Required%20Levels%20and%20Maps).\n\nFor example, `InteractionComponent_Overview`.\n\n\u003ca name=\"6.4.2\"\u003e\u003c/a\u003e\n\u003ca name=\"levels-mp-rules-demo\"\u003e\u003c/a\u003e\n#### 6.4.2 Demo Level\n\nIf your project contains assets that should be demoed or come with some sort of tutorial, you must have a map within your project that contains the name \"Demo\". This level should also contain documentation within it in some form that illustrates how to use your project. See Epic's Content Examples project for good examples on how to do this.\n\nIf your project is a gameplay mechanic or other form of system as opposed to an art pack, this can be the same as your \"Overview\" map.\n\nFor example, `InteractionComponent_Overview_Demo`, `ExplosionKit_Demo`.\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\n\u003ca name=\"7\"\u003e\u003c/a\u003e\n\u003ca name=\"textures\"\u003e\u003c/a\u003e\n## 7. Textures\n\nThis section will focus on Texture assets and their internals.\n\n\u003ca name=\"7.1\"\u003e\u003c/a\u003e\n\u003ca name=\"textures-dimensions\"\u003e\u003c/a\u003e\n### 7.1 Dimensions Are Powers of 2\n\nAll textures, except for UI textures, must have its dimensions in multiples of powers of 2. Textures do not have to be square.\n\nFor example, `128x512`, `1024x1024`, `2048x1024`, `1024x2048`, `1x512`.\n\n\u003ca name=\"7.2\"\u003e\u003c/a\u003e\n\u003ca name=\"textures-density\"\u003e\u003c/a\u003e\n### 7.2 Texture Density Should Be Uniform\n\nAll textures should be of a size appropriate for their standard use case. Appropriate texture density varies from project to project, but all textures within that project should have a consistent density.\n\nFor example, if a project's texture density is 8 pixel per 1 unit, a texture that is meant to be applied to a 100x100 unit cube should be 1024x1024, as that is the closest power of 2 that matches the project's texture density.\n\n\u003ca name=\"7.3\"\u003e\u003c/a\u003e\n\u003ca name=\"textures-max-size\"\u003e\u003c/a\u003e\n### 7.3 Textures Should Be No Bigger than 8192\n\nNo texture should have a dimension that exceeds 8192 in size, unless you have a very explicit reason to do so. Often, using a texture this big is simply just a waste of resources.\n\n\u003ca name=\"7.4\"\u003e\u003c/a\u003e\n\u003ca name=\"textures-group\"\u003e\u003c/a\u003e\n### 7.4 Textures Should Be Grouped Correctly\n\nEvery texture has a Texture Group property used for LODing, and this should be set correctly based on its use. For example, all UI textures should belong in the UI texture group.\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\n## Major Contributors\n\n* [Michael Allar](http://allarsblog.com): [GitHub](https://github.com/Allar), [Twitter](https://twitter.com/michaelallar)\n* [CosmoMyzrailGorynych](https://github.com/CosmoMyzrailGorynych)\n* [billymcguffin](https://github.com/billymcguffin)\n* [akenatsu](https://github.com/akenatsu)\n\n## License\n\nCopyright (c) 2016 Gamemakin LLC\n\nSee [LICENSE](/LICENSE)\n\n**[⬆ Back to Top](#table-of-contents)**\n\n\n## Amendments\n\nWe encourage you to fork this guide and change the rules to fit your team's style guide. Below, you may list some amendments to the style guide. This allows you to periodically update your style guide without having to deal with merge conflicts.\n\n# };\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fallar%2Fue5-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fallar%2Fue5-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fallar%2Fue5-style-guide/lists"}