├── .github └── FUNDING.yml ├── .gitignore ├── LICENSE ├── README.md ├── README_PTBR.md ├── docs ├── gettingstarted.md ├── howitworks.md ├── img │ ├── LintReport.png │ ├── LintRulesInBP.png │ ├── LintRulesMap.png │ ├── LinterLauncher.png │ ├── MarketplaceLintRuleSet.png │ ├── MarketplaceLinterFolder.png │ ├── ScanWithLinter.png │ └── ShowPluginContent.png ├── index.md ├── style.md ├── todo.md └── unrealguidelines.md ├── images ├── bp-graphs-align-wires-acceptable.png ├── bp-graphs-align-wires-bad.png └── bp-graphs-align-wires-good.png ├── marketplace-compatibility.md ├── mkdocs.yml └── readthedocs.yml /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # If you would like to directly support the maintenance of this repo and the pursuit of better things, please become a GitHub Sponsor or reach out to sponsor by other means. 2 | 3 | github: ALLAR 4 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | docs/build -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License 2 | 3 | Copyright (c) 2016 Gamemakin LLC. https://gamemak.in 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in 13 | all copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 21 | THE SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # [Gamemakin](https://gamemak.in) UE4 Style Guide() { 2 | 3 | *A mostly reasonable approach to Unreal Engine 4* 4 | 5 | Heavily inspired by the [Airbnb Javascript Style Guide](https://github.com/airbnb/javascript). 6 | 7 | [![Analytics](https://ga-beacon.appspot.com/UA-80567399-1/repo?useReferrer)](#) 8 | 9 | ## Repo Notice 10 | 11 | This repo is now located at https://github.com/Allar/ue5-style-guide. The default branch of this repository has been renamed `main`. 12 | 13 | ## This is currently for UE4. For UE5/v2, see the v2 branch 14 | ## Linter and Style Guide Documentation 15 | 16 | More technical documentation regarding Linter and the Style Guide can be found at our [ReadTheDocs](https://ue4-style-guide.readthedocs.io/en/latest/) page. 17 | 18 | ## Discuss This Style Guide 19 | 20 | Gamemakin 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. 21 | 22 | ## Linking To This Document 23 | 24 | Every 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 25 | For 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. 26 | 27 | ## Forks And Translations 28 | 29 | If 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. 30 | 31 | * [Korean Translation](https://github.com/ymkim50/ue4-style-guide/blob/master/README_Kor.md) by ymkim50 32 | * [Russian Translation](https://github.com/CosmoMyzrailGorynych/ue4-style-guide-rus/blob/master/README.md) by CosmoMyzrailGorynych 33 | * [Japanese Translation](https://github.com/akenatsu/ue4-style-guide/blob/master/README.jp.md) by akenatsu 34 | * [Chinese Translation](https://github.com/skylens-inc/ue4-style-guide/blob/master/README.md) by Beijing Skylens Tech. 35 | * [Brazilian Portuguese Translation](https://github.com/danlvr/ue5-style-guide/blob/main/README_PTBR.md) by danlvr. 36 | * [French Translation](https://github.com/Arnaud58/ue5-style-guide/blob/main/README.md) by Arnaud58 37 | 38 | ## Table of contents 39 | - [Important Terminology](#important-terminology) 40 | - [Levels/Maps](#terms-level-map) 41 | - [Identifiers](#terms-identifiers) 42 | - [Cases](#terms-cases) 43 | - [Variables / Properties](#terms-var-prop) 44 | - [Property](#terms-property) 45 | - [Variable](#terms-variable) 46 | - [0. Principles](#0) 47 | - [0.1 If your UE4 project already has a style guide, you should follow it](#0.1) 48 | - [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) 49 | - [0.3 Friends do not let friends have bad style](#0.3) 50 | - [0.4 A team without a style guide is no team of mine](#0.4) 51 | - [0.5 Don't Break The Law](#0.5) 52 | - [00. Globally Enforced Opinions](#00) 53 | - [00.1 Forbidden Characters](#00.1) 54 | - [Identifiers](#identifiers) 55 | - [1. Asset Naming Conventions](#anc) 56 | - [1.1 Base Asset Name - `Prefix_BaseAssetName_Variant_Suffix`](#base-asset-name) 57 | - [1.1 Examples](#1.1-examples) 58 | - [1.2 Asset Name Modifiers](#asset-name-modifiers) 59 | - [1.2.1 Most Common](#anc-common) 60 | - [1.2.2 Animations](#anc-animations) 61 | - [1.2.3 Artificial Intelligence](#anc-ai) 62 | - [1.2.4 Blueprints](#anc-bp) 63 | - [1.2.5 Materials](#anc-materials) 64 | - [1.2.6 Textures](#anc-textures) 65 | - [1.2.6.1 Texture Packing](#anc-textures-packing) 66 | - [1.2.7 Miscellaneous](#anc-misc) 67 | - [1.2.8 Paper 2D](#anc-paper2d) 68 | - [1.2.9 Physics](#anc-physics) 69 | - [1.2.10 Sounds](#anc-sounds) 70 | - [1.2.11 User Interface](#anc-ui) 71 | - [1.2.12 Effects](#anc-effects) 72 | - [2. Content Directory Structure](#structure) 73 | - [2e1 Example Project Content Structure](#2e1) 74 | - [2.1 Folder Names](#structure-folder-names) 75 | - [2.1.1 Always Use PascalCase](#2.1.1) 76 | - [2.1.2 Never Use Spaces](#2.1.2) 77 | - [2.1.3 Never Use Unicode Characters And Other Symbols](#2.1.3) 78 | - [2.2 Use A Top Level Folder For Project Specific Assets](#structure-top-level) 79 | - [2.2.1 No Global Assets](#2.2.1) 80 | - [2.2.2 Reduce Migration Conflicts](#2.2.2) 81 | - [2.2.2e1 Master Material Example](#2.2.2e1) 82 | - [2.2.3 Samples, Templates, and Marketplace Content Are Risk-Free](#2.2.3) 83 | - [2.2.4 DLC, Sub-Projects, and Patches Are Easily Maintained](#2.2.4) 84 | - [2.3 Use Developers Folder For Local Testing](#structure-developers) 85 | - [2.4 All Map* Files Belong In A Folder Called Maps](#structure-maps) 86 | - [2.5 Use A `Core` Folder For Critical Blueprints And Other Assets](#structure-core) 87 | - [2.6 Do Not Create Folders Called `Assets` or `AssetTypes`](#structure-assettypes) 88 | - [2.6.1 Creating a folder named `Assets` is redundant](#2.6.1) 89 | - [2.6.2 Creating a folder named `Meshes`, `Textures`, or `Materials` is redundant](#2.6.2) 90 | - [2.7 Very Large Asset Sets Get Their Own Folder Layout](#structure-large-sets) 91 | - [2.8 `MaterialLibrary`](#structure-material-library) 92 | - [2.9 No Empty Folders](#structure-no-empty-folders) 93 | - [3. Blueprints](#bp) 94 | - [3.1 Compiling](#bp-compiling) 95 | - [3.2 Variables](#bp-vars) 96 | - [3.2.1 Naming](#bp-var-naming) 97 | - [3.2.1.1 Nouns](#bp-var-naming-nouns) 98 | - [3.2.1.2 PascalCase](#bp-var-naming-case) 99 | - [3.2.1.2e Examples](#3.2.1.2e) 100 | - [3.2.1.3 Boolean `b` Prefix](#bp-var-bool-prefix) 101 | - [3.2.1.4 Boolean Names](#bp-var-bool-names) 102 | - [3.2.1.4.1 General And Independent State Information](#3.2.1.4.1) 103 | - [3.2.1.4.2 Complex States](#3.2.1.4.2) 104 | - [3.2.1.5 Considered Context](#bp-vars-naming-context) 105 | - [3.2.1.5e Examples](#3.2.1.5e) 106 | - [3.2.1.6 Do _Not_ Include Atomic Type Names](#bp-vars-naming-atomic) 107 | - [3.2.1.7 Do Include Non-Atomic Type Names](#bp-vars-naming-complex) 108 | - [3.2.1.8 Arrays](#bp-vars-naming-arrays) 109 | - [3.2.2 Editable Variables](#bp-vars-editable) 110 | - [3.2.2.1 Tooltips](#bp-vars-editable-tooltips) 111 | - [3.2.2.2 Slider And Value Ranges](#bp-vars-editable-ranges) 112 | - [3.2.3 Categories](#bp-vars-categories) 113 | - [3.2.4 Variable Access Level](#bp-vars-access) 114 | - [3.2.4.1 Private Variables](#bp-vars-access-private) 115 | - [3.2.5 Advanced Display](#bp-vars-advanced) 116 | - [3.2.6 Transient Variables](#bp-vars-transient) 117 | - [3.2.8 Config Variables](#bp-vars-config) 118 | - [3.3 Functions, Events, and Event Dispatchers](#bp-functions) 119 | - [3.3.1 Function Naming](#bp-funcs-naming) 120 | - [3.3.1.1 All Functions Should Be Verbs](#bp-funcs-naming-verbs) 121 | - [3.3.1.2 Property RepNotify Functions Always `OnRep_Variable`](#bp-funcs-naming-onrep) 122 | - [3.3.1.3 Info Functions Returning Bool Should Ask Questions](#bp-funcs-naming-bool) 123 | - [3.3.1.4 Event Handlers and Dispatchers Should Start With `On`](#bp-funcs-naming-eventhandlers) 124 | - [3.3.1.5 Remote Procedure Calls Should Be Prefixed With Target](#bp-funcs-naming-rpcs) 125 | - [3.3.2 All Functions Must Have Return Nodes](#bp-funcs-return) 126 | - [3.3.3 No Function Should Have More Than 50 Nodes](#bp-graphs-funcs-node-limit) 127 | - [3.3.4 All Public Functions Should Have A Description](#bp-graphs-funcs-description) 128 | - [3.3.5 All Custom Static Plugin `BlueprintCallable` Functions Must Be Categorized By Plugin Name](#bp-graphs-funcs-plugin-category) 129 | - [3.4 Blueprint Graphs](#bp-graphs) 130 | - [3.4.1 No Spaghetti](#bp-graphs-spaghetti) 131 | - [3.4.2 Align Wires Not Nodes](#bp-graphs-align-wires) 132 | - [3.4.3 White Exec Lines Are Top Priority](#bp-graphs-exec-first-class) 133 | - [3.4.4 Graphs Should Be Reasonably Commented](#bp-graphs-block-comments) 134 | - [3.4.5 Graphs Should Handle Casting Errors Where Appropriate](#bp-graphs-cast-error-handling) 135 | - [3.4.6 Graphs Should Not Have Any Dangling / Loose / Dead Nodes](#bp-graphs-dangling-nodes) 136 | - [4. Static Meshes](#4) 137 | - [4.1 Static Mesh UVs](#s-uvs) 138 | - [4.1.1 All Meshes Must Have UVs](#s-uvs-no-missing) 139 | - [4.1.2 All Meshes Must Not Have Overlapping UVs for Lightmaps](#s-uvs-no-overlapping) 140 | - [4.2 LODs Should Be Set Up Correctly](#s-lods) 141 | - [4.3 Modular Socketless Assets Should Snap To The Grid Cleanly](#s-modular-snapping) 142 | - [4.4 All Meshes Must Have Collision](#s-collision) 143 | - [4.5 All Meshes Should Be Scaled Correctly](#s-scaled) 144 | - [5. Niagara](#Niagara) 145 | - [5.1 No Spaces, Ever](#ng-rules) 146 | - [6. Levels / Maps](#levels) 147 | - [6.1 No Errors Or Warnings](#levels-no-errors-or-warnings) 148 | - [6.2 Lighting Should Be Built](#levels-lighting-should-be-built) 149 | - [6.3 No Player Visible Z Fighting](#levels-no-visible-z-fighting) 150 | - [6.4 Marketplace Specific Rules](#levels-mp-rules) 151 | - [6.4.1 Overview Level](#levels-mp-rules-overview) 152 | - [6.4.2 Demo Level](#levels-mp-rules-demo) 153 | - [7. Textures](#textures) 154 | - [7.1 Dimensions Are Powers of 2](#textures-dimensions) 155 | - [7.2 Texture Density Should Be Uniform](#textures-density) 156 | - [7.3 Textures Should Be No Bigger than 8192](#textures-max-size) 157 | - [7.4 Textures Should Be Grouped Correctly](#textures-group) 158 | 159 | ## Important Terminology 160 | 161 | 162 | ##### Levels/Maps 163 | 164 | The 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)). 165 | 166 | 167 | ##### Identifiers 168 | An `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... 169 | 170 | 171 | ##### Cases 172 | 173 | There are a few different ways you can `CaseWordsWhenNaming`. Here are some common casing types: 174 | 175 | > ###### PascalCase 176 | > 177 | > Capitalize every word and remove all spaces, e.g. `DesertEagle`, `StyleGuide`, `ASeriesOfWords`. 178 | > 179 | > ###### camelCase 180 | > 181 | > The first letter is always lowercase but every following word starts with uppercase, e.g. `desertEagle`, `styleGuide`, `aSeriesOfWords`. 182 | > 183 | > ###### Snake_case 184 | > 185 | > Words can arbitrarily start upper or lowercase but words are separated by an underscore, e.g. `desert_Eagle`, `Style_Guide`, `a_Series_of_Words`. 186 | 187 | 188 | ##### Variables / Properties 189 | 190 | The words 'variable' and 'property' in most contexts are interchangable. If they are both used together in the same context however: 191 | 192 | 193 | ###### Property 194 | Usually 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`. 195 | 196 | When in the context of a class, it is often used to imply accessing previously defined data. 197 | 198 | 199 | ###### Variable 200 | Usually refers to a variable defined as a function argument or a local variable inside a function. 201 | 202 | When in the context of a class, it is often used to convey discussion about its definition and what it will hold. 203 | 204 | 205 | ## 0. Principles 206 | 207 | These principles have been adapted from [idomatic.js style guide](https://github.com/rwaldron/idiomatic.js/). 208 | 209 | 210 | ### 0.1 If your UE4 project already has a style guide, you should follow it 211 | 212 | If 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. 213 | 214 | Style 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. 215 | 216 | > #### "Arguments over style are pointless. There should be a style guide, and you should follow it." 217 | > [_Rebecca Murphey_](https://rmurphey.com) 218 | 219 | 220 | ### 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 221 | 222 | Moving 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. 223 | 224 | It 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. 225 | 226 | 227 | ### 0.3 Friends do not let friends have bad style 228 | 229 | If you see someone working either against a style guide or no style guide, try to correct them. 230 | 231 | When 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. 232 | 233 | If 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. 234 | 235 | 236 | ### 0.4 A team without a style guide is no team of mine 237 | 238 | When 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. 239 | 240 | 241 | ### 0.5 Don't Break The Law 242 | 243 | Gamemakin LLC is not a lawyer, but please don't introduce illegal actions and behavior to a project, including but not limited to: 244 | 245 | * Don't distribute content you don't have the rights to distribute 246 | * Don't infringe on someone else's copyrighted or trademark material 247 | * Don't steal content 248 | * Follow licensing restrictions on content, e.g. attribute when attributions are needed 249 | 250 | 251 | ## 00. Globally Enforced Opinions 252 | 253 | @TODO: Make this section 1 and update this document accordingly. Or maybe we don't? 254 | 255 | 256 | ### 00.1 Forbidden Characters 257 | 258 | 259 | #### Identifiers 260 | 261 | In any `Identifier` of any kind, **never** use the following unless absolutely forced to: 262 | 263 | * White space of any kind 264 | * Backward slashes `\` 265 | * Symbols i.e. `#!@$%` 266 | * Any Unicode character 267 | 268 | Any `Identifier` should strive to only have the following characters when possible (the RegEx `[A-Za-z0-9_]+`) 269 | 270 | * ABCDEFGHIJKLMNOPQRSTUVWXYZ 271 | * abcdefghijklmnopqrstuvwxyz 272 | * 1234567890 273 | * _ (sparingly) 274 | 275 | The 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. 276 | 277 | 278 | 279 | ## 1. Asset Naming Conventions 280 | 281 | Naming 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. 282 | 283 | Most things are prefixed with prefixes being generally an acronym of the asset type followed by an underscore. 284 | 285 | 286 | 287 | ### 1.1 Base Asset Name - `Prefix_BaseAssetName_Variant_Suffix` 288 | 289 | All 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`. 290 | 291 | Keeping 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. 292 | 293 | `Prefix` and `Suffix` are to be determined by the asset type through the following [Asset Name Modifier](#asset-name-modifiers) tables. 294 | 295 | `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`. 296 | 297 | For 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`. 298 | 299 | For 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. 300 | 301 | Depending 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`. 302 | 303 | 304 | #### 1.1 Examples 305 | 306 | ##### 1.1e1 Bob 307 | 308 | | Asset Type | Asset Name | 309 | | ----------------------- | ---------------------------------------------------------- | 310 | | Skeletal Mesh | SK_Bob | 311 | | Material | M_Bob | 312 | | Texture (Diffuse/Albedo)| T_Bob_D | 313 | | Texture (Normal) | T_Bob_N | 314 | | Texture (Evil Diffuse) | T_Bob_Evil_D | 315 | 316 | ##### 1.1e2 Rocks 317 | 318 | | Asset Type | Asset Name | 319 | | ----------------------- | ---------------------------------------------------------- | 320 | | Static Mesh (01) | S_Rock_01 | 321 | | Static Mesh (02) | S_Rock_02 | 322 | | Static Mesh (03) | S_Rock_03 | 323 | | Material | M_Rock | 324 | | Material Instance (Snow)| MI_Rock_Snow | 325 | 326 | 327 | 328 | ### 1.2 Asset Name Modifiers 329 | 330 | When naming an asset, use these tables to determine the prefix and suffix to use with an asset's [Base Asset Name](#base-asset-name). 331 | 332 | 333 | 334 | #### 1.2.1 Most Common 335 | 336 | | Asset Type | Prefix | Suffix | Notes | 337 | | ----------------------- | ---------- | ---------- | -------------------------------- | 338 | | Level / Map | | | [Should be in a folder called Maps.](#2.4) | 339 | | Level (Persistent) | | _P | | 340 | | Level (Audio) | | _Audio | | 341 | | Level (Lighting) | | _Lighting | | 342 | | Level (Geometry) | | _Geo | | 343 | | Level (Gameplay) | | _Gameplay | | 344 | | Blueprint | BP_ | | | 345 | | Material | M_ | | | 346 | | Static Mesh | S_ | | Many use SM_. We use S_. | 347 | | Skeletal Mesh | SK_ | | | 348 | | Texture | T_ | _? | See [Textures](#anc-textures) | 349 | | Particle System | PS_ | | | 350 | | Widget Blueprint | WBP_ | | | 351 | 352 | 353 | 354 | #### 1.2.2 Animations 355 | 356 | | Asset Type | Prefix | Suffix | Notes | 357 | | ----------------------- | ---------- | ---------- | -------------------------------- | 358 | | Aim Offset | AO_ | | | 359 | | Aim Offset 1D | AO_ | | | 360 | | Animation Blueprint | ABP_ | | | 361 | | Animation Composite | AC_ | | | 362 | | Animation Montage | AM_ | | | 363 | | Animation Sequence | A_ | | | 364 | | Blend Space | BS_ | | | 365 | | Blend Space 1D | BS_ | | | 366 | | Level Sequence | LS_ | | | 367 | | Morph Target | MT_ | | | 368 | | Paper Flipbook | PFB_ | | | 369 | | Rig | Rig_ | | | 370 | | Skeletal Mesh | SK_ | | | 371 | | Skeleton | SKEL_ | | | 372 | 373 | 374 | 375 | ### 1.2.3 Artificial Intelligence 376 | 377 | | Asset Type | Prefix | Suffix | Notes | 378 | | ----------------------- | ---------- | ---------- | -------------------------------- | 379 | | AI Controller | AIC_ | | | 380 | | Behavior Tree | BT_ | | | 381 | | Blackboard | BB_ | | | 382 | | Decorator | BTDecorator_ | | | 383 | | Service | BTService_ | | | 384 | | Task | BTTask_ | | | 385 | | Environment Query | EQS_ | | | 386 | | EnvQueryContext | EQS_ | Context | | 387 | 388 | 389 | 390 | ### 1.2.4 Blueprints 391 | 392 | | Asset Type | Prefix | Suffix | Notes | 393 | | ----------------------- | ---------- | ---------- | -------------------------------- | 394 | | Blueprint | BP_ | | | 395 | | Blueprint Component | BP_ | Component | I.e. BP_InventoryComponent | 396 | | Blueprint Function Library | BPFL_ | | | 397 | | Blueprint Interface | BPI_ | | | 398 | | Blueprint Macro Library | BPML_ | | Do not use macro libraries if possible. | 399 | | Enumeration | E | | No underscore. | 400 | | Structure | F or S | | No underscore. | 401 | | Tutorial Blueprint | TBP_ | | | 402 | | Widget Blueprint | WBP_ | | | 403 | 404 | 405 | 406 | ### 1.2.5 Materials 407 | 408 | | Asset Type | Prefix | Suffix | Notes | 409 | | ----------------------------- | ---------- | ---------- | -------------------------------- | 410 | | Material | M_ | | | 411 | | Material (Post Process) | PP_ | | | 412 | | Material Function | MF_ | | | 413 | | Material Instance | MI_ | | | 414 | | Material Parameter Collection | MPC_ | | | 415 | | Subsurface Profile | SP_ | | | 416 | | Physical Materials | PM_ | | | 417 | | Decal | M_, MI_ | _Decal | | 418 | 419 | 420 | 421 | ### 1.2.6 Textures 422 | 423 | | Asset Type | Prefix | Suffix | Notes | 424 | | ----------------------- | ---------- | ---------- | -------------------------------- | 425 | | Texture | T_ | | | 426 | | Texture (Diffuse/Albedo/Base Color)| T_ | _D | | 427 | | Texture (Normal) | T_ | _N | | 428 | | Texture (Roughness) | T_ | _R | | 429 | | Texture (Alpha/Opacity) | T_ | _A | | 430 | | Texture (Ambient Occlusion) | T_ | _O | | 431 | | Texture (Bump) | T_ | _B | | 432 | | Texture (Emissive) | T_ | _E | | 433 | | Texture (Mask) | T_ | _M | | 434 | | Texture (Specular) | T_ | _S | | 435 | | Texture (Metallic) | T_ | _M | | 436 | | Texture (Packed) | T_ | _* | See notes below about [packing](#anc-textures-packing). | 437 | | Texture Cube | TC_ | | | 438 | | Media Texture | MT_ | | | 439 | | Render Target | RT_ | | | 440 | | Cube Render Target | RTC_ | | | 441 | | Texture Light Profile | TLP | | | 442 | 443 | 444 | 445 | #### 1.2.6.1 Texture Packing 446 | It 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`. 447 | 448 | > 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. 449 | 450 | Packing 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. 451 | 452 | 453 | 454 | ### 1.2.7 Miscellaneous 455 | 456 | | Asset Type | Prefix | Suffix | Notes | 457 | | -------------------------- | ---------- | ---------- | -------------------------------- | 458 | | Animated Vector Field | VFA_ | | | 459 | | Camera Anim | CA_ | | | 460 | | Color Curve | Curve_ | _Color | | 461 | | Curve Table | Curve_ | _Table | | 462 | | Data Asset | *_ | | Prefix should be based on class. | 463 | | Data Table | DT_ | | | 464 | | Float Curve | Curve_ | _Float | | 465 | | Foliage Type | FT_ | | | 466 | | Force Feedback Effect | FFE_ | | | 467 | | Landscape Grass Type | LG_ | | | 468 | | Landscape Layer | LL_ | | | 469 | | Matinee Data | Matinee_ | | | 470 | | Media Player | MP_ | | | 471 | | File Media Source | FMS_ | | | 472 | | Object Library | OL_ | | | 473 | | Redirector | | | These should be fixed up ASAP. | 474 | | Sprite Sheet | SS_ | | | 475 | | Static Vector Field | VF_ | | | 476 | | Substance Graph Instance | SGI_ | | | 477 | | Substance Instance Factory | SIF_ | | | 478 | | Touch Interface Setup | TI_ | | | 479 | | Vector Curve | Curve_ | _Vector | | 480 | 481 | 482 | 483 | ### 1.2.8 Paper 2D 484 | 485 | | Asset Type | Prefix | Suffix | Notes | 486 | | ----------------------- | ---------- | ---------- | -------------------------------- | 487 | | Paper Flipbook | PFB_ | | | 488 | | Sprite | SPR_ | | | 489 | | Sprite Atlas Group | SPRG_ | | | 490 | | Tile Map | TM_ | | | 491 | | Tile Set | TS_ | | | 492 | 493 | 494 | 495 | ### 1.2.9 Physics 496 | 497 | | Asset Type | Prefix | Suffix | Notes | 498 | | ----------------------- | ---------- | ---------- | -------------------------------- | 499 | | Physical Material | PM_ | | | 500 | | Physics Asset | PHYS_ | | | 501 | | Destructible Mesh | DM_ | | | 502 | 503 | 504 | 505 | ### 1.2.10 Sounds 506 | 507 | | Asset Type | Prefix | Suffix | Notes | 508 | | ----------------------- | ---------- | ---------- | -------------------------------- | 509 | | Dialogue Voice | DV_ | | | 510 | | Dialogue Wave | DW_ | | | 511 | | Media Sound Wave | MSW_ | | | 512 | | Reverb Effect | Reverb_ | | | 513 | | Sound Attenuation | ATT_ | | | 514 | | Sound Class | | | No prefix/suffix. Should be put in a folder called SoundClasses | 515 | | Sound Concurrency | | _SC | Should be named after a SoundClass | 516 | | Sound Cue | A_ | _Cue | | 517 | | Sound Mix | Mix_ | | | 518 | | Sound Wave | A_ | | | 519 | 520 | 521 | 522 | ### 1.2.11 User Interface 523 | 524 | | Asset Type | Prefix | Suffix | Notes | 525 | | ----------------------- | ---------- | ---------- | -------------------------------- | 526 | | Font | Font_ | | | 527 | | Slate Brush | Brush_ | | | 528 | | Slate Widget Style | Style_ | | | 529 | | Widget Blueprint | WBP_ | | | 530 | 531 | 532 | 533 | ### 1.2.12 Effects 534 | 535 | | Asset Type | Prefix | Suffix | Notes | 536 | | ----------------------- | ---------- | ---------- | -------------------------------- | 537 | | Particle System | PS_ | | | 538 | | Material (Post Process) | PP_ | | | 539 | 540 | **[⬆ Back to Top](#table-of-contents)** 541 | 542 | 543 | 544 | ## 2. Content Directory Structure 545 | 546 | Equally 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. 547 | 548 | There 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. 549 | 550 | > 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. 551 | 552 | 553 | ### 2e1 Example Project Content Structure 554 | 
 555 | |-- Content
 556 |     |-- GenericShooter
 557 |         |-- Art
 558 |         |   |-- Industrial
 559 |         |   |   |-- Ambient
 560 |         |   |   |-- Machinery
 561 |         |   |   |-- Pipes
 562 |         |   |-- Nature
 563 |         |   |   |-- Ambient
 564 |         |   |   |-- Foliage
 565 |         |   |   |-- Rocks
 566 |         |   |   |-- Trees
 567 |         |   |-- Office
 568 |         |-- Characters
 569 |         |   |-- Bob
 570 |         |   |-- Common
 571 |         |   |   |-- Animations
 572 |         |   |   |-- Audio
 573 |         |   |-- Jack
 574 |         |   |-- Steve
 575 |         |   |-- Zoe
 576 |         |-- Core
 577 |         |   |-- Characters
 578 |         |   |-- Engine
 579 |         |   |-- GameModes
 580 |         |   |-- Interactables
 581 |         |   |-- Pickups
 582 |         |   |-- Weapons
 583 |         |-- Effects
 584 |         |   |-- Electrical
 585 |         |   |-- Fire
 586 |         |   |-- Weather
 587 |         |-- Maps
 588 |         |   |-- Campaign1
 589 |         |   |-- Campaign2
 590 |         |-- MaterialLibrary
 591 |         |   |-- Debug
 592 |         |   |-- Metal
 593 |         |   |-- Paint
 594 |         |   |-- Utility
 595 |         |   |-- Weathering
 596 |         |-- Placeables
 597 |         |   |-- Pickups
 598 |         |-- Weapons
 599 |             |-- Common
 600 |             |-- Pistols
 601 |             |   |-- DesertEagle
 602 |             |   |-- RocketPistol
 603 |             |-- Rifles
 604 |
605 | 606 | The reasons for this structure are listed in the following sub-sections. 607 | 608 | 609 | 610 | ### 2.1 Folder Names 611 | 612 | These are common rules for naming any folder in the content structure. 613 | 614 | 615 | #### 2.1.1 Always Use PascalCase[*](#terms-cases) 616 | 617 | PascalCase 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`. 618 | 619 | See [Cases](#terms-cases). 620 | 621 | 622 | #### 2.1.2 Never Use Spaces 623 | 624 | Re-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`. 625 | 626 | 627 | #### 2.1.3 Never Use Unicode Characters And Other Symbols 628 | 629 | If 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. 630 | 631 | Related 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. 632 | 633 | Using 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. 634 | 635 | 636 | 637 | ### 2.2 Use A Top Level Folder For Project Specific Assets 638 | 639 | All 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`. 640 | 641 | > 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. 642 | 643 | There are multiple reasons for this approach. 644 | 645 | 646 | #### 2.2.1 No Global Assets 647 | 648 | Often 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. 649 | 650 | Every 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. 651 | 652 | 653 | #### 2.2.2 Reduce Migration Conflicts 654 | 655 | When 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. 656 | 657 | These 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. 658 | 659 | This is also the primary reason why Epic's Marketplace staff enforces the same policy for submitted assets. 660 | 661 | After 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. 662 | 663 | 664 | ##### 2.2.2e1 Master Material Example 665 | 666 | For 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. 667 | 668 | As 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. 669 | 670 | The 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. 671 | 672 | This 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. 673 | 674 | It 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. 675 | 676 | 677 | #### 2.2.3 Samples, Templates, and Marketplace Content Are Risk-Free 678 | 679 | An 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. 680 | 681 | You 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. 682 | 683 | When 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. 684 | 685 | 686 | #### 2.2.4 DLC, Sub-Projects, and Patches Are Easily Maintained 687 | 688 | If 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. 689 | 690 | 691 | 692 | ### 2.3 Use Developers Folder For Local Testing 693 | 694 | During 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. 695 | 696 | It 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. 697 | 698 | If 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. 699 | 700 | Once 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. 701 | 702 | 703 | 704 | ### 2.4 All Map[*](#terms-level-map) Files Belong In A Folder Called Maps 705 | 706 | Map 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`. 707 | 708 | Being 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`. 709 | 710 | This 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. 711 | 712 | 713 | 714 | ### 2.5 Use A `Core` Folder For Critical Blueprints And Other Assets 715 | 716 | Use `/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. 717 | 718 | This 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. 719 | 720 | For 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. 721 | 722 | 723 | 724 | ### 2.6 Do Not Create Folders Called `Assets` or `AssetTypes` 725 | 726 | 727 | #### 2.6.1 Creating a folder named `Assets` is redundant 728 | 729 | All assets are assets. 730 | 731 | 732 | #### 2.6.2 Creating a folder named `Meshes`, `Textures`, or `Materials` is redundant 733 | 734 | All 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. 735 | 736 | Want 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. 737 | 738 | > 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. 739 | 740 | Not doing this also prevents the inevitability of someone putting a static mesh or a texture in a `Materials` folder. 741 | 742 | 743 | 744 | ### 2.7 Very Large Asset Sets Get Their Own Folder Layout 745 | 746 | This can be seen as a pseudo-exception to [2.6](#2.6). 747 | 748 | There 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. 749 | 750 | For example, animations that are shared across multiple characters should lay in `Characters/Common/Animations` and may have sub-folders such as `Locomotion` or `Cinematic`. 751 | 752 | > 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). 753 | 754 | 755 | 756 | ### 2.8 `MaterialLibrary` 757 | 758 | If 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`. 759 | 760 | This way all 'global' materials have a place to live and are easily located. 761 | 762 | > 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`. 763 | 764 | The `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`. 765 | 766 | Any 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. 767 | 768 | 769 | 770 | ### 2.9 No Empty Folders 771 | 772 | There simply shouldn't be any empty folders. They clutter the content browser. 773 | 774 | If you find that the content browser has an empty folder you can't delete, you should perform the following: 775 | 1. Be sure you're using source control. 776 | 1. Immediately run Fix Up Redirectors on your project. 777 | 1. Navigate to the folder on-disk and delete the assets inside. 778 | 1. Close the editor. 779 | 1. Make sure your source control state is in sync (i.e. if using Perforce, run a Reconcile Offline Work on your content directory) 780 | 1. Open the editor. Confirm everything still works as expected. If it doesn't, revert, figure out what went wrong, and try again. 781 | 1. Ensure the folder is now gone. 782 | 1. Submit changes to source control. 783 | 784 | **[⬆ Back to Top](#table-of-contents)** 785 | 786 | 787 | 788 | 789 | ## 3. Blueprints 790 | 791 | This 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). 792 | 793 | Remember: Blueprinting badly bears blunders, beware! (Phrase by [KorkuVeren](http://github.com/KorkuVeren)) 794 | 795 | 796 | 797 | ### 3.1 Compiling 798 | 799 | All 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. 800 | 801 | Do *not* submit broken blueprints to source control. If you must store them on source control, shelve them instead. 802 | 803 | Broken 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. 804 | 805 | 806 | 807 | ### 3.2 Variables 808 | 809 | The words `variable` and `property` may be used interchangeably. 810 | 811 | 812 | 813 | #### 3.2.1 Naming 814 | 815 | 816 | 817 | ##### 3.2.1.1 Nouns 818 | 819 | All non-boolean variable names must be clear, unambiguous, and descriptive nouns. 820 | 821 | 822 | 823 | ##### 3.2.1.2 PascalCase 824 | 825 | All non-boolean variables should be in the form of [PascalCase](#terms-cases). 826 | 827 | 828 | ###### 3.2.1.2e Examples 829 | 830 | * `Score` 831 | * `Kills` 832 | * `TargetPlayer` 833 | * `Range` 834 | * `CrosshairColor` 835 | * `AbilityID` 836 | 837 | 838 | 839 | ##### 3.2.1.3 Boolean `b` Prefix 840 | 841 | All booleans should be named in PascalCase but prefixed with a lowercase `b`. 842 | 843 | Example: Use `bDead` and `bEvil`, **not** `Dead` and `Evil`. 844 | 845 | UE4 Blueprint editors know not to include the `b` in user-friendly displays of the variable. 846 | 847 | 848 | 849 | ##### 3.2.1.4 Boolean Names 850 | 851 | 852 | ###### 3.2.1.4.1 General And Independent State Information 853 | 854 | All 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. 855 | 856 | Example: Use `bDead` and `bHostile` **not** `bIsDead` and `bIsHostile`. 857 | 858 | Try to not use verbs such as `bRunning`. Verbs tend to lead to complex states. 859 | 860 | 861 | ###### 3.2.1.4.2 Complex States 862 | 863 | Do 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. 864 | 865 | Example: 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. 866 | 867 | Example: Do **not** use `bRunning` if you also need `bWalking` or `bSprinting`. This should be defined as an enumeration with clearly defined state names. 868 | 869 | 870 | 871 | ##### 3.2.1.5 Considered Context 872 | 873 | All variable names must not be redundant with their context as all variable references in Blueprint will always have context. 874 | 875 | 876 | ###### 3.2.1.5e Examples 877 | 878 | Consider a Blueprint called `BP_PlayerCharacter`. 879 | 880 | **Bad** 881 | 882 | * `PlayerScore` 883 | * `PlayerKills` 884 | * `MyTargetPlayer` 885 | * `MyCharacterName` 886 | * `CharacterSkills` 887 | * `ChosenCharacterSkin` 888 | 889 | All 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. 890 | 891 | **Good** 892 | 893 | * `Score` 894 | * `Kills` 895 | * `TargetPlayer` 896 | * `Name` 897 | * `Skills` 898 | * `Skin` 899 | 900 | 901 | 902 | ##### 3.2.1.6 Do _Not_ Include Atomic Type Names 903 | 904 | Atomic or primitive variables are variables that represent data in their simplest form, such as booleans, integers, floats, and enumerations. 905 | 906 | Strings and vectors are considered atomic in terms of style when working with Blueprints, however they are technically not atomic. 907 | 908 | > While vectors consist of three floats, vectors are often able to be manipulated as a whole, same with rotators. 909 | 910 | > 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`. 911 | 912 | Atomic variables should not have their type name in their name. 913 | 914 | Example: Use `Score`, `Kills`, and `Description` **not** `ScoreFloat`, `FloatKills`, `DescriptionString`. 915 | 916 | The 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. 917 | 918 | Example: 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`. 919 | 920 | 921 | 922 | ##### 3.2.1.7 Do Include Non-Atomic Type Names 923 | 924 | Non-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. 925 | 926 | > While an Array of an atomic variable type is a list of variables, Arrays do not change the 'atomicness' of a variable type. 927 | 928 | These variables should include their type name while still considering their context. 929 | 930 | If 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. 931 | 932 | Example: Use `Hat`, `Flag`, and `Ability` **not** `MyHat`, `MyFlag`, and `PlayerAbility`. 933 | 934 | If a class does not own the value a complex variable represents, you should use a noun along with the variable type. 935 | 936 | Example: 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. 937 | 938 | 939 | 940 | 941 | ##### 3.2.1.8 Arrays 942 | 943 | Arrays follow the same naming rules as above, but should be named as a plural noun. 944 | 945 | Example: Use `Targets`, `Hats`, and `EnemyPlayers`, **not** `TargetList`, `HatArray`, `EnemyPlayerArray`. 946 | 947 | 948 | 949 | 950 | #### 3.2.2 Editable Variables 951 | 952 | All variables that are safe to change the value of in order to configure behavior of a blueprint should be marked as `Editable`. 953 | 954 | Conversely, 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`. 955 | 956 | Do not arbitrarily mark variables as `Editable`. 957 | 958 | 959 | 960 | ##### 3.2.2.1 Tooltips 961 | 962 | All `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. 963 | 964 | 965 | 966 | ##### 3.2.2.2 Slider And Value Ranges 967 | 968 | All `Editable` variables should make use of slider and value ranges if there is ever a value that a variable should _not_ be set to. 969 | 970 | Example: 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. 971 | 972 | If 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. 973 | 974 | A 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. 975 | 976 | 977 | 978 | #### 3.2.3 Categories 979 | 980 | If a class has only a small number of variables, categories are not required. 981 | 982 | If 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`. 983 | 984 | If 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. 985 | 986 | > You can define sub-categories by using the pipe character `|`, i.e. `Config | Animations`. 987 | 988 | Example: A weapon class set of variables might be organized as: 989 | 990 | |-- Config 991 | | |-- Animations 992 | | |-- Effects 993 | | |-- Audio 994 | | |-- Recoil 995 | | |-- Timings 996 | |-- Animations 997 | |-- State 998 | |-- Visuals 999 | 1000 | 1001 | 1002 | #### 3.2.4 Variable Access Level 1003 | 1004 | In 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. 1005 | 1006 | Blueprints do not have a defined concept of protected access currently. 1007 | 1008 | Treat `Editable` variables as public variables. Treat non-editable variables as protected variables. 1009 | 1010 | 1011 | 1012 | ##### 3.2.4.1 Private Variables 1013 | 1014 | Unless 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. 1015 | 1016 | 1017 | 1018 | #### 3.2.5 Advanced Display 1019 | 1020 | If 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. 1021 | 1022 | To find the `Advanced Display` option, it is listed as an advanced displayed variable in the variable details list. 1023 | 1024 | 1025 | 1026 | #### 3.2.6 Transient Variables 1027 | 1028 | Transient 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. 1029 | 1030 | Because of this, all transient variables should always be initialized as zero or null. To do otherwise would result in hard to debug errors. 1031 | 1032 | 1033 | 1034 | #### 3.2.8 Config Variables 1035 | 1036 | Do 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. 1037 | 1038 | 1039 | 1040 | ### 3.3 Functions, Events, and Event Dispatchers 1041 | 1042 | This section describes how you should author functions, events, and event dispatchers. Everything that applies to functions also applies to events, unless otherwise noted. 1043 | 1044 | 1045 | 1046 | #### 3.3.1 Function Naming 1047 | 1048 | The naming of functions, events, and event dispatchers is critically important. Based on the name alone, certain assumptions can be made about functions. For example: 1049 | 1050 | * Is it a pure function? 1051 | * Is it fetching state information? 1052 | * Is it a handler? 1053 | * Is it an RPC? 1054 | * What is its purpose? 1055 | 1056 | These questions and more can all be answered when functions are named appropriately. 1057 | 1058 | 1059 | 1060 | #### 3.3.1.1 All Functions Should Be Verbs 1061 | 1062 | All 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. 1063 | 1064 | `OnRep` functions, event handlers, and event dispatchers are an exception to this rule. 1065 | 1066 | Good examples: 1067 | 1068 | * `Fire` - Good example if in a Character / Weapon class, as it has context. Bad if in a Barrel / Grass / any ambiguous class. 1069 | * `Jump` - Good example if in a Character class, otherwise, needs context. 1070 | * `Explode` 1071 | * `ReceiveMessage` 1072 | * `SortPlayerArray` 1073 | * `GetArmOffset` 1074 | * `GetCoordinates` 1075 | * `UpdateTransforms` 1076 | * `EnableBigHeadMode` 1077 | * `IsEnemy` - ["Is" is a verb.](http://writingexplained.org/is-is-a-verb) 1078 | 1079 | Bad examples: 1080 | 1081 | * `Dead` - Is Dead? Will deaden? 1082 | * `Rock` 1083 | * `ProcessData` - Ambiguous, these words mean nothing. 1084 | * `PlayerState` - Nouns are ambiguous. 1085 | * `Color` - Verb with no context, or ambiguous noun. 1086 | 1087 | 1088 | 1089 | #### 3.3.1.2 Property RepNotify Functions Always `OnRep_Variable` 1090 | 1091 | All 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. 1092 | 1093 | 1094 | 1095 | #### 3.3.1.3 Info Functions Returning Bool Should Ask Questions 1096 | 1097 | When 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). 1098 | 1099 | This 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. 1100 | 1101 | Good examples: 1102 | 1103 | * `IsDead` 1104 | * `IsOnFire` 1105 | * `IsAlive` 1106 | * `IsSpeaking` 1107 | * `IsHavingAnExistentialCrisis` 1108 | * `IsVisible` 1109 | * `HasWeapon` - ["Has" is a verb.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html) 1110 | * `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'. 1111 | * `CanReload` - ["Can" is a verb.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html) 1112 | 1113 | Bad examples: 1114 | 1115 | * `Fire` - Is on fire? Will fire? Do fire? 1116 | * `OnFire` - Can be confused with event dispatcher for firing. 1117 | * `Dead` - Is dead? Will deaden? 1118 | * `Visibility` - Is visible? Set visibility? A description of flying conditions? 1119 | 1120 | 1121 | 1122 | #### 3.3.1.4 Event Handlers and Dispatchers Should Start With `On` 1123 | 1124 | Any 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. 1125 | 1126 | [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. 1127 | 1128 | `Handle` is not allowed. It is 'Unreal' to use `On` instead of `Handle`, while other frameworks may prefer to use `Handle` instead of `On`. 1129 | 1130 | Good examples: 1131 | 1132 | * `OnDeath` - Common collocation in games 1133 | * `OnPickup` 1134 | * `OnReceiveMessage` 1135 | * `OnMessageRecieved` 1136 | * `OnTargetChanged` 1137 | * `OnClick` 1138 | * `OnLeave` 1139 | 1140 | Bad examples: 1141 | 1142 | * `OnData` 1143 | * `OnTarget` 1144 | * `HandleMessage` 1145 | * `HandleDeath` 1146 | 1147 | 1148 | 1149 | #### 3.3.1.5 Remote Procedure Calls Should Be Prefixed With Target 1150 | 1151 | Any time an RPC is created, it should be prefixed with either `Server`, `Client`, or `Multicast`. No exceptions. 1152 | 1153 | After the prefix, follow all other rules regarding function naming. 1154 | 1155 | Good examples: 1156 | 1157 | * `ServerFireWeapon` 1158 | * `ClientNotifyDeath` 1159 | * `MulticastSpawnTracerEffect` 1160 | 1161 | Bad examples: 1162 | 1163 | * `FireWeapon` - Does not indicate its an RPC of some kind. 1164 | * `ServerClientBroadcast` - Confusing. 1165 | * `AllNotifyDeath` - Use `Multicast`, never `All`. 1166 | * `ClientWeapon` - No verb, ambiguous. 1167 | 1168 | 1169 | 1170 | 1171 | #### 3.3.2 All Functions Must Have Return Nodes 1172 | 1173 | All functions must have return nodes, no exceptions. 1174 | 1175 | Return 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. 1176 | 1177 | The 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. 1178 | 1179 | In 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. 1180 | 1181 | 1182 | 1183 | #### 3.3.3 No Function Should Have More Than 50 Nodes 1184 | 1185 | Simply, 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. 1186 | 1187 | The following nodes are not counted as they are deemed to not increase function complexity: 1188 | 1189 | * Comment 1190 | * Route 1191 | * Cast 1192 | * Getting a Variable 1193 | * Breaking a Struct 1194 | * Function Entry 1195 | * Self 1196 | 1197 | 1198 | 1199 | #### 3.3.4 All Public Functions Should Have A Description 1200 | 1201 | This rule applies more to public facing or marketplace blueprints, so that others can more easily navigate and consume your blueprint API. 1202 | 1203 | Simply, any function that has an access specificer of Public should have its description filled out. 1204 | 1205 | 1206 | 1207 | #### 3.3.5 All Custom Static Plugin `BlueprintCallable` Functions Must Be Categorized By Plugin Name 1208 | 1209 | If 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. 1210 | 1211 | For example, `Zed Camera Interface` or `Zed Camera Interface | Image Capturing`. 1212 | 1213 | 1214 | 1215 | ### 3.4 Blueprint Graphs 1216 | 1217 | This section covers things that apply to all Blueprint graphs. 1218 | 1219 | 1220 | 1221 | #### 3.4.1 No Spaghetti 1222 | 1223 | Wires 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. 1224 | 1225 | 1226 | 1227 | #### 3.4.2 Align Wires Not Nodes 1228 | 1229 | Always 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 1230 | 1231 | Good example: The tops of the nodes are staggered to keep a perfectly straight white exec line. 1232 | ![Aligned By Wires](https://github.com/Allar/ue5-style-guide/blob/main/images/bp-graphs-align-wires-good.png?raw=true "Aligned By Wires") 1233 | 1234 | Bad Example: The tops of the nodes are aligned creating a wiggly white exec line. 1235 | ![Bad](https://github.com/Allar/ue5-style-guide/blob/main/images/bp-graphs-align-wires-bad.png?raw=true "Wiggly") 1236 | 1237 | Acceptable 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. 1238 | ![Acceptable](https://github.com/Allar/ue5-style-guide/blob/main/images/bp-graphs-align-wires-acceptable.png?raw=true "Acceptable") 1239 | 1240 | 1241 | 1242 | #### 3.4.3 White Exec Lines Are Top Priority 1243 | 1244 | If 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. 1245 | 1246 | 1247 | 1248 | #### 3.4.4 Graphs Should Be Reasonably Commented 1249 | 1250 | Blocks 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. 1251 | 1252 | 1253 | 1254 | #### 3.4.5 Graphs Should Handle Casting Errors Where Appropriate 1255 | 1256 | If 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. 1257 | 1258 | This 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. 1259 | 1260 | 1261 | 1262 | #### 3.4.6 Graphs Should Not Have Any Dangling / Loose / Dead Nodes 1263 | 1264 | All 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. 1265 | 1266 | **[⬆ Back to Top](#table-of-contents)** 1267 | 1268 | 1269 | 1270 | 1271 | 1272 | ## 4. Static Meshes 1273 | 1274 | This section will focus on Static Mesh assets and their internals. 1275 | 1276 | 1277 | 1278 | ### 4.1 Static Mesh UVs 1279 | 1280 | If 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. 1281 | 1282 | 1283 | 1284 | #### 4.1.1 All Meshes Must Have UVs 1285 | 1286 | Pretty simple. All meshes, regardless how they are to be used, should not be missing UVs. 1287 | 1288 | 1289 | 1290 | #### 4.1.2 All Meshes Must Not Have Overlapping UVs for Lightmaps 1291 | 1292 | Pretty simple. All meshes, regardless how they are to be used, should have valid non-overlapping UVs. 1293 | 1294 | 1295 | 1296 | ### 4.2 LODs Should Be Set Up Correctly 1297 | 1298 | This 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. 1299 | 1300 | 1301 | 1302 | ### 4.3 Modular Socketless Assets Should Snap To The Grid Cleanly 1303 | 1304 | This 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. 1305 | 1306 | It 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. 1307 | 1308 | 1309 | 1310 | ### 4.4 All Meshes Must Have Collision 1311 | 1312 | Regardless 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. 1313 | 1314 | 1315 | 1316 | ### 4.5 All Meshes Should Be Scaled Correctly 1317 | 1318 | This 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. 1319 | 1320 | **[⬆ Back to Top](#table-of-contents)** 1321 | 1322 | 1323 | 1324 | 1325 | 1326 | ## 5. Niagara 1327 | 1328 | This section will focus on Niagara assets and their internals. 1329 | 1330 | 1331 | 1332 | ### 5.1 No Spaces, Ever 1333 | 1334 | As 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. 1335 | 1336 | (Original Contribution by [@dunenkoff](https://github.com/Allar/ue5-style-guide/issues/58)) 1337 | 1338 | 1339 | **[⬆ Back to Top](#table-of-contents)** 1340 | 1341 | 1342 | 1343 | 1344 | 1345 | ## 6. Levels / Maps 1346 | 1347 | [See Terminology Note](#terms-level-map) regarding "levels" vs "maps". 1348 | 1349 | This section will focus on Level assets and their internals. 1350 | 1351 | 1352 | 1353 | ### 6.1 No Errors Or Warnings 1354 | 1355 | All 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. 1356 | 1357 | You can run a map check on an open level in the editor by using the console command "map check". 1358 | 1359 | Please 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. 1360 | 1361 | 1362 | 1363 | ### 6.2 Lighting Should Be Built 1364 | 1365 | It 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. 1366 | 1367 | 1368 | 1369 | ### 6.3 No Player Visible Z Fighting 1370 | 1371 | Levels should not have any [z-fighting](https://en.wikipedia.org/wiki/Z-fighting) in all areas visible to the player. 1372 | 1373 | 1374 | 1375 | ### 6.4 Marketplace Specific Rules 1376 | 1377 | If a project is to be sold on the UE4 Marketplace, it must follow these rules. 1378 | 1379 | 1380 | 1381 | #### 6.4.1 Overview Level 1382 | 1383 | If your project contains assets that should be visualized or demoed, you must have a map within your project that contains the name "Overview". 1384 | 1385 | This 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). 1386 | 1387 | For example, `InteractionComponent_Overview`. 1388 | 1389 | 1390 | 1391 | #### 6.4.2 Demo Level 1392 | 1393 | If 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. 1394 | 1395 | If 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. 1396 | 1397 | For example, `InteractionComponent_Overview_Demo`, `ExplosionKit_Demo`. 1398 | 1399 | **[⬆ Back to Top](#table-of-contents)** 1400 | 1401 | 1402 | 1403 | 1404 | ## 7. Textures 1405 | 1406 | This section will focus on Texture assets and their internals. 1407 | 1408 | 1409 | 1410 | ### 7.1 Dimensions Are Powers of 2 1411 | 1412 | All textures, except for UI textures, must have its dimensions in multiples of powers of 2. Textures do not have to be square. 1413 | 1414 | For example, `128x512`, `1024x1024`, `2048x1024`, `1024x2048`, `1x512`. 1415 | 1416 | 1417 | 1418 | ### 7.2 Texture Density Should Be Uniform 1419 | 1420 | All 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. 1421 | 1422 | For 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. 1423 | 1424 | 1425 | 1426 | ### 7.3 Textures Should Be No Bigger than 8192 1427 | 1428 | No 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. 1429 | 1430 | 1431 | 1432 | ### 7.4 Textures Should Be Grouped Correctly 1433 | 1434 | Every 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. 1435 | 1436 | **[⬆ Back to Top](#table-of-contents)** 1437 | 1438 | 1439 | ## Major Contributors 1440 | 1441 | * [Michael Allar](http://allarsblog.com): [GitHub](https://github.com/Allar), [Twitter](https://twitter.com/michaelallar) 1442 | * [CosmoMyzrailGorynych](https://github.com/CosmoMyzrailGorynych) 1443 | * [billymcguffin](https://github.com/billymcguffin) 1444 | * [akenatsu](https://github.com/akenatsu) 1445 | 1446 | ## License 1447 | 1448 | Copyright (c) 2016 Gamemakin LLC 1449 | 1450 | See [LICENSE](/LICENSE) 1451 | 1452 | **[⬆ Back to Top](#table-of-contents)** 1453 | 1454 | 1455 | ## Amendments 1456 | 1457 | We 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. 1458 | 1459 | # }; 1460 | -------------------------------------------------------------------------------- /README_PTBR.md: -------------------------------------------------------------------------------- 1 | # [Gamemakin](https://gamemak.in) UE4 - Guia de Estilo() { 2 | 3 | *Uma abordagem bastante razoável para Unreal Engine 4* 4 | 5 | Inspirado pelo [Guia de Estilo Airbnb Javascript](https://github.com/airbnb/javascript). 6 | 7 | [![Analytics](https://ga-beacon.appspot.com/UA-80567399-1/repo?useReferrer)](#) 8 | 9 | ## Nota de tradução 10 | 11 | Foram mantidos os nomes e expressões em inglês comumente usadas na Unreal Engine e.x. "texture", "material", "asset", etc. 12 | 13 | ## Aviso de Repo 14 | 15 | O repo original agora está localizado em https://github.com/Allar/ue5-style-guide. O branch padrão deste repositório foi renomeado `main`. 16 | 17 | ## Atualmente, é para UE4. 18 | ## Documentação do Guia de Estilo e Linter 19 | 20 | Mais documentação técnicas sobre o Linter e o Guia de Estilo pode ser encontrada na página: [LeiaOsDocumentos](https://ue4-style-guide.readthedocs.io/en/latest/). 21 | 22 | ## Debata este guia de estilo 23 | 24 | Gamemakin LLC tem um canal Discord público em http://discord.gamemak.in com um canal #linter se você gostaria de debater sobre o Guia de Estilo e o plugin Linter. 25 | 26 | ## Link para este documento 27 | 28 | Cada seção deste Guia de Estilo é numerada para facilitar a referência e o link. Você pode vincular a qualquer seção diretamente acrescentando uma hashtag e o número da seção ao final de http://ue4.style 29 | Por exemplo, se você deseja enviar a alguém o primeiro princípio deste Guia de Estilo, você deve colocar `#0.1`, resultando em http://ue4.style#0.1. 30 | 31 | ## Forks e Traduções 32 | 33 | Se você fez um fork ou tradução que não é adequada para uma solicitação pull neste repo, envie uma solicitação pull para adicionar sua fork ou tradução aqui. 34 | 35 | * [Tradução para Coreano](https://github.com/ymkim50/ue4-style-guide/blob/master/README_Kor.md) por ymkim50 36 | * [Tradução para Russo](https://github.com/CosmoMyzrailGorynych/ue4-style-guide-rus/blob/master/README.md) por CosmoMyzrailGorynych 37 | * [Tradução para Japonês](https://github.com/akenatsu/ue4-style-guide/blob/master/README.jp.md) por akenatsu 38 | * [Tradução para Chinês](https://github.com/skylens-inc/ue4-style-guide/blob/master/README.md) por Beijing Skylens Tech. 39 | * [Tradução para Português do Brasil](https://github.com/danlvr/ue5-style-guide/blob/main/README_PTBR.md) por danlvr. 40 | 41 | ## Terminologia Importante 42 | 43 | 44 | ##### Levels/Maps 45 | 46 | A palavra 'map' geralmente se refere ao que a pessoa chama de 'level' e pode ser usado indistintamente. Veja a história deste termo [aqui](https://en.wikipedia.org/wiki/Level_(video_gaming)). 47 | 48 | ##### Identifiers 49 | Um `Identifier` é qualquer coisa que se pareça ou sirva como um "nome". Por exemplo, o nome de um "asset", ou o nome de um "material", ou a propriedade de um "blueprint", uma variável, ou um nome de pasta, ou para um nome de uma linha de tabela de dados, etc... 50 | 51 | 52 | ##### Caixa Alta e Caixa Baixa 53 | 54 | Existem algumas maneiras diferentes de você `NomearComCaixaAltaOuCaixaBaixa`. Aqui estão alguns tipos mais comuns: 55 | 56 | > ###### PascalCase 57 | > 58 | > Capitalize cada palavra e remova todos os espaços, e.x. `DesertEagle`, `GuiaDeEstilos`, `UmaSerieDePalavras`. 59 | > 60 | > ###### camelCase 61 | > 62 | > A primeira letra é sempre minúscula mas todas as palavras seguintes começam com maiúsculas, e.x. `desertEagle`, `guiaDeEstilos`, `umaSerieDePalavras`. 63 | > 64 | > ###### Snake_case 65 | > 66 | > As palavras podem começar arbitrariamente com letras maiúsculas ou minúsculas, mas as palavras são separadas por um sublinhado, e.g. `desert_Eagle`, `Guia_de_Estilos`, `uma_Serie_de_Palavras`. 67 | 68 | 69 | ##### Variáveis / Propriedades 70 | 71 | As palavras 'variável' e 'propriedade' na maioria dos contextos são intercambiáveis. No entanto, se ambas forem usados juntos no mesmo contexto considere: 72 | 73 | 74 | ###### Propriedade 75 | Normalmente se refere a uma variável definida em uma classe. Por exemplo, se `BP_Barril` tinha uma variável `bExplodiu`, `bExplodiu` pode ser referido como uma propriedade de `BP_Barril`. 76 | 77 | Quando no contexto de uma classe, muitas vezes é usado para implicar o acesso a dados previamente definidos. 78 | 79 | 80 | ###### Variável 81 | Normalmente se refere a uma variável definida como um argumento de função ou uma variável local dentro de uma função. 82 | 83 | Quando no contexto de uma classe, é freqüentemente usado para transmitir um debate sobre sua definição e o que ela conterá. 84 | 85 | 86 | ## 0. Princípios 87 | 88 | Esses princípios foram adaptados de [guida de estilo idomatic.js](https://github.com/rwaldron/idiomatic.js/). 89 | 90 | 91 | ### 0.1 Se o seu projeto UE4 já tem um Guia de Estilo, você deve segui-lo. 92 | 93 | Se você estiver trabalhando em um projeto ou com uma equipe que possui um guia de estilo pré-existente, ele deve ser respeitado. Qualquer inconsistência entre um guia de estilo existente e este guia, deve-se seguir o existente. 94 | 95 | Os guias de estilo devem ser documentos vivos. Você deve propor alterações de guia de estilo a um guia de estilo existente, bem como a este guia, se achar que a alteração beneficia todos os seus usos. 96 | 97 | > #### "Discussões sobre o estilo são desnecessárias. Deve sempre haver um Guia de Estilo e você deve segui-lo." 98 | > [_Rebecca Murphey_](https://rmurphey.com) 99 | 100 | 101 | ### 0.2 Toda estrutura, assets e código em qualquer projeto Unreal Engine 4 devem parecer que foram criados por uma única pessoa, não importa quantas pessoas contribuíram. 102 | 103 | Mudar de um projeto para outro não deve causar uma reaprendizagem de estilo e estrutura. A conformidade com um Guia de Estilo remove suposições e ambigüidades desnecessárias. 104 | 105 | Também permite uma criação e manutenção mais produtivas, pois não é necessário pensar no estilo. Simplesmente siga as instruções. Este guia de estilo foi escrito com as práticas recomendadas em mente, o que significa que, ao seguir este guia de estilo, você também minimizará problemas difíceis de rastrear. 106 | 107 | 108 | ### 0.3 Amigos não deixam amigos terem estilo ruim. 109 | 110 | Se você vir alguém trabalhando contra um guia de estilo ou sem nenhum guia de estilo, tente corrigi-lo. 111 | 112 | Ao trabalhar em uma equipe ou discutir em uma comunidade, como a [Unreal Slackers](http://join.unrealslackers.org/), é muito mais fácil ajudar e pedir ajuda quando as pessoas são consistentes. Ninguém gosta de ajudar a desemaranhar o "espaguete" do Blueprint de alguém ou lidar com assets que tenham nomes que eles não conseguem entender. 113 | 114 | Se você está ajudando alguém cujo trabalho segue um Guia de Estilo diferente, mas consistente e lógico, você deve ser capaz de se adaptar a ele. Se eles não estiverem de acordo com nenhum Guia de Estilo, indique-os aqui. 115 | 116 | 117 | ### 0.4 Uma equipe sem um Guia de Estilo não é a minha equipe. 118 | 119 | Ao ingressar em uma equipe Unreal Engine 4, uma de suas primeiras perguntas deve ser "Você tem um Guia de Estilo?". Se a resposta for não, você deve duvidar da capacidade deles de trabalhar em equipe. 120 | 121 | 122 | ### 0.5 Não quebre a lei 123 | 124 | A Gamemakin LLC não é composta por advogados, mas não introduza ações e comportamentos ilegais em um projeto, incluindo, mas não se limitando a: 125 | 126 | * Não distribua conteúdo para o qual você não tem os direitos de distribuição 127 | * Não infrinja o material protegido por direitos autorais ou marca registrada de outra pessoa 128 | * Não roube conteúdo 129 | * Siga as restrições de licenciamento de conteúdo, por exemplo atributo quando as atribuições são necessárias 130 | 131 | 132 | ## 00. Opiniões Globalmente Impostas 133 | 134 | @TODO: Faça esta a Seção 1 e atualize este documento de acordo. Ou talvez não? 135 | 136 | 137 | ### 00.1 Caracteres Proibidos 138 | 139 | #### Identifiers 140 | 141 | Em qualquer `Identifier` de qualquer tipo, **nunca** use o seguinte, a menos que seja obrigado: 142 | 143 | * Espaço em branco de qualquer tipo 144 | * Barras invertidas `\` 145 | * Símbolos e.x. `#!@$%` 146 | * Qualquer caractere Unicode 147 | 148 | Um `Identifier` deve ter apenas os seguintes caracteres, quando possível (expressão regular `[A-Za-z0-9_]+`) 149 | 150 | * ABCDEFGHIJKLMNOPQRSTUVWXYZ 151 | * abcdefghijklmnopqrstuvwxyz 152 | * 1234567890 153 | * _ (moderadamente) 154 | 155 | 156 | O motivo para isso é que garantirá a maior compatibilidade de todos os dados em todas as plataformas em todas as ferramentas e ajudará a evitar o tempo de inatividade devido ao tratamento potencialmente incorreto de caracteres para identificadores em códigos que você não controla. 157 | 158 | 159 | ## Índice 160 | 161 | > 1. [Convenções de nomenclatura de assets](#anc) 162 | > 1. [Estrutura de Diretório](#structure) 163 | > 1. [Blueprints](#bp) 164 | > 1. [Static Meshes](#s) 165 | > 1. [Particle Systems](#ps) 166 | > 1. [Levels / Maps](#levels) 167 | > 1. [Textures](#textures) 168 | 169 | 170 | 171 | ## 1. Convenções de Nomenclatura de Assets 172 | 173 | As convenções de nomenclatura devem ser tratadas como lei. Um projeto que está em conformidade com uma convenção de nomenclatura pode ter seus assets gerenciados, pesquisados, analisados e mantidos com uma facilidade incrível. 174 | 175 | Geralmente são prefixadas com um acrônimo do tipo de asset seguido por um sublinhado (_). 176 | 177 | 178 | 179 | ### 1.1 Nome Base do Asset - `Prefixo_NomeBaseDoAsset_Variante_Sufixo` 180 | 181 | Todos os assets devem ter um _Nome Base do Asset_. Um nome de asset básico representa um agrupamento lógico de assets relacionados. Qualquer asset que faça parte deste grupo lógico deve seguir o padrão de `Prefixo_NomeBaseDoAsset_Variante_Sufixo`. 182 | 183 | Mantendo o padrão `Prefixo_NomeBaseDoAsset_Variante_Sufixo` em mente e usar o bom senso geralmente é suficiente para garantir bons nomes de assets. Aqui estão algumas regras detalhadas sobre cada elemento. 184 | 185 | `Prefixo` e `Sufixo` devem ser determinados pelo tipo de asset por meio do seguinte tabelas de [Modificador do Nome do Asset](#asset-name-modifiers). 186 | 187 | `NomeBaseDoAsset` deve ser determinado por um nome curto e facilmente reconhecível relacionado ao contexto desse grupo de assets. Por exemplo, se você tivesse um personagem chamado Bob, todos os assets de Bob teriam o `NomeBaseDoAsset` de `Bob`. 188 | 189 | Para variações únicas e específicas de assets, `Variante` é um nome curto e facilmente reconhecível que representa o agrupamento lógico de assets que são um subconjunto do nome de base de um asset. Por exemplo, se Bob tinha várias skins, essas skins ainda deveriam usar `Bob` assim como `NomeBaseDoAsset` mas inclua um reconhecível `Variante`. Uma skin 'Evil' seria referida como `Bob_Evil` e uma skin 'Retro' seria referida como `Bob_Retro`. 190 | 191 | Para variações únicas, mas genéricas de assets, `Variante` é um número de dois dígitos começando em `01`. Por exemplo, se você tem um Ambient Designer gerando rochas indefinidas, eles seriam nomeadas `Rocha_01`, `Rocha_02`, `Rocha_03`, etc. Exceto em raras exceções, você nunca deve exigir um número de variante de três dígitos. Se você tiver mais de 100 assets, deve considerar organizá-los com nomes de base diferentes ou usando vários nomes de variantes. 192 | 193 | Dependendo de como suas variantes de assets são feitas, você pode encadear nomes de variantes. Por exemplo, se você estiver criando assets de piso para um projeto Arch Viz, você deve usar o nome de base `Piso` com variantes em cadeia, como `Piso_Marmore_01`, `Piso_Bordo_01`, `Piso_Tile_Quadrados_01`. 194 | 195 | 196 | #### 1.1 Exemplos 197 | 198 | ##### 1.1e1 Bob 199 | 200 | | Tipo de Asset | Nome do Asset | 201 | | ----------------------- | ---------------------------------------------------------- | 202 | | Skeletal Mesh | SK_Bob | 203 | | Material | M_Bob | 204 | | Texture (Diffuse/Albedo)| T_Bob_D | 205 | | Texture (Normal) | T_Bob_N | 206 | | Texture (Evil Diffuse) | T_Bob_Evil_D | 207 | 208 | ##### 1.1e2 Rocha 209 | 210 | | Tipo de Asset | Nome do Asset | 211 | | ----------------------- | ---------------------------------------------------------- | 212 | | Static Mesh (01) | S_Rocha_01 | 213 | | Static Mesh (02) | S_Rocha_02 | 214 | | Static Mesh (03) | S_Rocha_03 | 215 | | Material | M_Rocha | 216 | | Material Instance (Neve)| MI_Rocha_Neve | 217 | 218 | 219 | 220 | ### 1.2 Modificadores de Nome de Asset 221 | 222 | Ao nomear um asset, use essas tabelas para determinar o prefixo e sufixo a ser usado com ele [Nome Base do Asset](#base-asset-name). 223 | 224 | #### Sections 225 | 226 | > 1.2.1 [Mais comum](#anc-common) 227 | 228 | > 1.2.2 [Animações](#anc-animations) 229 | 230 | > 1.2.3 [Inteligência Artificial](#anc-ai) 231 | 232 | > 1.2.4 [Blueprints](#anc-bp) 233 | 234 | > 1.2.5 [Materials](#anc-materials) 235 | 236 | > 1.2.6 [Textures](#anc-textures) 237 | 238 | > 1.2.7 [Miscelâneas](#anc-misc) 239 | 240 | > 1.2.8 [Paper 2D](#anc-paper2d) 241 | 242 | > 1.2.9 [Física](#anc-physics) 243 | 244 | > 1.2.10 [Som](#anc-sounds) 245 | 246 | > 1.2.11 [Interface de Usuário](#anc-ui) 247 | 248 | > 1.2.12 [Efeitos](#anc-effects) 249 | 250 | 251 | 252 | #### 1.2.1 Mais comum 253 | 254 | | Tipo de Asset | Prefixo | Suffixo | Notas | 255 | | ----------------------- | ---------- | ---------- | -------------------------------- | 256 | | Level / Mapas | | | [Deve estar em uma pasta chamada Maps.](#2.4) | 257 | | Level (Persistente) | | _P | | 258 | | Level (Audio) | | _Audio | | 259 | | Level (Iluminação) | | _Lighting | | 260 | | Level (Geometria) | | _Geo | | 261 | | Level (Gameplay) | | _Gameplay | | 262 | | Blueprint | BP_ | | | 263 | | Material | M_ | | | 264 | | Static Mesh | S_ | | Muitos usam SM_. Usamos S_. | 265 | | Skeletal Mesh | SK_ | | | 266 | | Texture | T_ | _? | Veja [Textures](#anc-textures) | 267 | | Particle System | PS_ | | | 268 | | Widget Blueprint | WBP_ | | | 269 | 270 | 271 | 272 | #### 1.2.2 Animações 273 | 274 | | Tipo de Asset | Prefixo | Suffixo | Notas | 275 | | ----------------------- | ---------- | ---------- | -------------------------------- | 276 | | Aim Offset | AO_ | | | 277 | | Aim Offset 1D | AO_ | | | 278 | | Animation Blueprint | ABP_ | | | 279 | | Animation Composite | AC_ | | | 280 | | Animation Montage | AM_ | | | 281 | | Animation Sequence | A_ | | | 282 | | Blend Space | BS_ | | | 283 | | Blend Space 1D | BS_ | | | 284 | | Level Sequence | LS_ | | | 285 | | Morph Target | MT_ | | | 286 | | Paper Flipbook | PFB_ | | | 287 | | Rig | Rig_ | | | 288 | | Skeletal Mesh | SK_ | | | 289 | | Skeleton | SKEL_ | | | 290 | 291 | 292 | 293 | ### 1.2.3 Inteligência Artificial 294 | 295 | | Tipo de Asset | Prefixo | Suffixo | Notas | 296 | | ----------------------- | ---------- | ---------- | -------------------------------- | 297 | | AI Controller | AIC_ | | | 298 | | Behavior Tree | BT_ | | | 299 | | Blackboard | BB_ | | | 300 | | Decorator | BTDecorator_ | | | 301 | | Service | BTService_ | | | 302 | | Task | BTTask_ | | | 303 | | Environment Query | EQS_ | | | 304 | | EnvQueryContext | EQS_ | Contexto | | 305 | 306 | 307 | 308 | ### 1.2.4 Blueprints 309 | 310 | | Tipo de Asset | Prefixo | Suffixo | Notas | 311 | | ----------------------- | ---------- | ---------- | -------------------------------- | 312 | | Blueprint | BP_ | | | 313 | | Blueprint Component | BP_ | Component | E.x. BP_InventoryComponent | 314 | | Blueprint Function Library | BPFL_ | | | 315 | | Blueprint Interface | BPI_ | | | 316 | | Blueprint Macro Library | BPML_ | | Não use bibliotecas de macro, se possível. | 317 | | Enumeration | E | | Sem sublinhado. | 318 | | Structure | F or S | | Sem sublinhado. | 319 | | Tutorial Blueprint | TBP_ | | | 320 | | Widget Blueprint | WBP_ | | | 321 | 322 | 323 | 324 | ### 1.2.5 Materials 325 | 326 | | Tipo de Asset | Prefixo | Suffixo | Notas | 327 | | ----------------------------- | ---------- | ---------- | -------------------------------- | 328 | | Material | M_ | | | 329 | | Material (Post Process) | PP_ | | | 330 | | Material Function | MF_ | | | 331 | | Material Instance | MI_ | | | 332 | | Material Parameter Collection | MPC_ | | | 333 | | Subsurface Profile | SP_ | | | 334 | | Physical Materials | PM_ | | | 335 | | Decal | M_, MI_ | _Decal | | 336 | 337 | 338 | 339 | ### 1.2.6 Textures 340 | 341 | | Tipo de Asset | Prefixo | Suffixo | Notas | 342 | | ----------------------- | ---------- | ---------- | -------------------------------- | 343 | | Texture | T_ | | | 344 | | Texture (Diffuse/Albedo/Base Color)| T_ | _D | | 345 | | Texture (Normal) | T_ | _N | | 346 | | Texture (Roughness) | T_ | _R | | 347 | | Texture (Alpha/Opacity) | T_ | _A | | 348 | | Texture (Ambient Occlusion) | T_ | _O | | 349 | | Texture (Bump) | T_ | _B | | 350 | | Texture (Emissive) | T_ | _E | | 351 | | Texture (Mask) | T_ | _M | | 352 | | Texture (Specular) | T_ | _S | | 353 | | Texture (Metallic) | T_ | _M | | 354 | | Texture (Packed) | T_ | _* | Veja as notas abaixo sobre [pacotes](#anc-textures-packing). | 355 | | Texture Cube | TC_ | | | 356 | | Media Texture | MT_ | | | 357 | | Render Target | RT_ | | | 358 | | Cube Render Target | RTC_ | | | 359 | | Texture Light Profile | TLP | | | 360 | 361 | 362 | 363 | #### 1.2.6.1 Pacote de textura 364 | É uma prática comum compactar várias camadas de dados de textura em uma única textura. Um exemplo disso é agregar "Emissive", "Roughness", "Ambient Occlusion" juntos como os canais Vermelho, Verde e Azul de uma textura, respectivamente. Para determinar o sufixo, basta empilhar as letras de sufixo fornecidas de cima, e.g. `_ERO`. 365 | 366 | > É geralmente aceitável incluir uma camada Alfa/Opacidade no canal Alfa de Difusão/Albedo e, como essa é uma prática comum, adicionar `A` ao sufixo` _D` é opcional. 367 | 368 | Englobar 4 canais de dados em uma textura (RGBA) não é recomendado, exceto para uma máscara Alfa/Opacidade no canal Alfa de Difusão/Albedo, pois uma textura com um canal alfa incorre em mais sobrecarga do que uma sem. 369 | 370 | 371 | 372 | ### 1.2.7 Miscelâneas 373 | 374 | | Tipo de Asset | Prefixo | Suffixo | Notas | 375 | | -------------------------- | ---------- | ---------- | -------------------------------- | 376 | | Animated Vector Field | VFA_ | | | 377 | | Camera Anim | CA_ | | | 378 | | Color Curve | Curve_ | _Color | | 379 | | Curve Table | Curve_ | _Table | | 380 | | Data Asset | *_ | | O prefixo deve ser baseado na classe. | 381 | | Data Table | DT_ | | | 382 | | Float Curve | Curve_ | _Float | | 383 | | Foliage Type | FT_ | | | 384 | | Force Feedback Effect | FFE_ | | | 385 | | Landscape Grass Type | LG_ | | | 386 | | Landscape Layer | LL_ | | | 387 | | Matinee Data | Matinee_ | | | 388 | | Media Player | MP_ | | | 389 | | Object Library | OL_ | | | 390 | | Redirector | | | Estes devem ser consertados o mais rápido possível. | 391 | | Sprite Sheet | SS_ | | | 392 | | Static Vector Field | VF_ | | | 393 | | Substance Graph Instance | SGI_ | | | 394 | | Substance Instance Factory | SIF_ | | | 395 | | Touch Interface Setup | TI_ | | | 396 | | Vector Curve | Curve_ | _Vector | | 397 | 398 | 399 | 400 | ### 1.2.8 Paper 2D 401 | 402 | | Tipo de Asset | Prefixo | Suffixo | Notas | 403 | | ----------------------- | ---------- | ---------- | -------------------------------- | 404 | | Paper Flipbook | PFB_ | | | 405 | | Sprite | SPR_ | | | 406 | | Sprite Atlas Group | SPRG_ | | | 407 | | Tile Map | TM_ | | | 408 | | Tile Set | TS_ | | | 409 | 410 | 411 | 412 | ### 1.2.9 Física 413 | 414 | | Tipo de Asset | Prefixo | Suffixo | Notas | 415 | | ----------------------- | ---------- | ---------- | -------------------------------- | 416 | | Physical Material | PM_ | | | 417 | | Physics Asset | PHYS_ | | | 418 | | Destructible Mesh | DM_ | | | 419 | 420 | 421 | 422 | ### 1.2.10 Som 423 | 424 | | Tipo de Asset | Prefixo | Suffixo | Notas | 425 | | ----------------------- | ---------- | ---------- | -------------------------------- | 426 | | Dialogue Voice | DV_ | | | 427 | | Dialogue Wave | DW_ | | | 428 | | Media Sound Wave | MSW_ | | | 429 | | Reverb Effect | Reverb_ | | | 430 | | Sound Attenuation | ATT_ | | | 431 | | Sound Class | | | Sem prefixo/sufixo. Deve ser colocado em uma pasta chamada SoundClasses | 432 | | Sound Concurrency | | _SC | Deve ter o nome de uma SoundClass | 433 | | Sound Cue | A_ | _Cue | | 434 | | Sound Mix | Mix_ | | | 435 | | Sound Wave | A_ | | | 436 | 437 | 438 | 439 | ### 1.2.11 Interface de Usuário 440 | 441 | | Tipo de Asset | Prefixo | Suffixo | Notas | 442 | | ----------------------- | ---------- | ---------- | -------------------------------- | 443 | | Font | Font_ | | | 444 | | Slate Brush | Brush_ | | | 445 | | Slate Widget Style | Style_ | | | 446 | | Widget Blueprint | WBP_ | | | 447 | 448 | 449 | 450 | ### 1.2.12 Efeitos 451 | 452 | | Tipo de Asset | Prefixo | Suffixo | Notas | 453 | | ----------------------- | ---------- | ---------- | -------------------------------- | 454 | | Particle System | PS_ | | | 455 | | Material (Post Process) | PP_ | | | 456 | 457 | **[⬆ Voltar ao topo](#table-of-contents)** 458 | 459 | 460 | 461 | 462 | ## 2. Estrutura do Diretório de Conteúdo 463 | 464 | Tão importante quanto os nomes de assets, o estilo da estrutura de diretório de um projeto deve ser considerado lei. As convenções de nomenclatura de assets e a estrutura do diretório de conteúdo andam de mãos dadas, e a violação de qualquer uma delas causa um caos desnecessário. 465 | 466 | Existem várias maneiras de definir o conteúdo de um projeto UE4. Nesse estilo, usaremos uma estrutura que depende mais dos recursos de filtragem e pesquisa do Navegador de Conteúdo para aqueles que trabalham com assets para encontrar assets de um tipo específico, em vez de outra estrutura comum que agrupa tipos de assets com pastas. 467 | 468 | > Se você estiver usando o prefixo [convenção de nomenclatura] (# 1.2) acima, usar pastas para conter assets de tipos semelhantes, como `Meshes`,` Textures` e `Materials` é uma prática redundante, pois os tipos de assets já são classificados por prefixo, bem como podem ser filtrado no Navegador de Conteúdo. 469 | 470 | 471 | ### 2e1 Exemplo de Estrutura de Conteúdo do Projeto 472 | 
 473 | |-- Content
 474 |     |-- GenericShooter
 475 |         |-- Art
 476 |         |   |-- Industrial
 477 |         |   |   |-- Ambient
 478 |         |   |   |-- Machinery
 479 |         |   |   |-- Pipes
 480 |         |   |-- Nature
 481 |         |   |   |-- Ambient
 482 |         |   |   |-- Foliage
 483 |         |   |   |-- Rocks
 484 |         |   |   |-- Trees
 485 |         |   |-- Office
 486 |         |-- Characters
 487 |         |   |-- Bob
 488 |         |   |-- Common
 489 |         |   |   |-- Animations
 490 |         |   |   |-- Audio
 491 |         |   |-- Jack
 492 |         |   |-- Steve
 493 |         |   |-- Zoe
 494 |         |-- Core
 495 |         |   |-- Characters
 496 |         |   |-- Engine
 497 |         |   |-- GameModes
 498 |         |   |-- Interactables
 499 |         |   |-- Pickups
 500 |         |   |-- Weapons
 501 |         |-- Effects
 502 |         |   |-- Electrical
 503 |         |   |-- Fire
 504 |         |   |-- Weather
 505 |         |-- Maps
 506 |         |   |-- Campaign1
 507 |         |   |-- Campaign2
 508 |         |-- MaterialLibrary
 509 |         |   |-- Debug
 510 |         |   |-- Metal
 511 |         |   |-- Paint
 512 |         |   |-- Utility
 513 |         |   |-- Weathering
 514 |         |-- Placeables
 515 |         |   |-- Pickups
 516 |         |-- Weapons
 517 |             |-- Common
 518 |             |-- Pistols
 519 |             |   |-- DesertEagle
 520 |             |   |-- RocketPistol
 521 |             |-- Rifles
 522 |
523 | 524 | Os motivos para essa estrutura estão listados nas subseções a seguir. 525 | 526 | ### Seções 527 | 528 | > 2.1 [Nomes de pasta](#structure-folder-names) 529 | 530 | > 2.2 [Pasta de Nível Superior](#structure-top-level) 531 | 532 | > 2.3 [Pastas de desenvolvedor](#structure-developers) 533 | 534 | > 2.4 [Maps](#structure-maps) 535 | 536 | > 2.5 [Core](#structure-core) 537 | 538 | > 2.6 [`Assets` e `AssetTypes`](#structure-assettypes) 539 | 540 | > 2.7 [Conjuntos Grandes](#structure-large-sets) 541 | 542 | > 2.8 [Biblioteca de Materiais](#structure-material-library) 543 | 544 | 545 | 546 | 547 | ### 2.1 Nomes de pasta 548 | 549 | Essas são regras comuns para nomear qualquer pasta na estrutura de conteúdo. 550 | 551 | 552 | #### 2.1.1 Sempre use PascalCase[*](#terms-cases) 553 | 554 | PascalCase refere-se a iniciar um nome com uma letra maiúscula e, em vez de usar espaços, todas as palavras seguintes também começam com uma letra maiúscula. Por exemplo, `DesertEagle`, `RocketPistol`, e `UmaSerieDePalavras`. 555 | 556 | Veja [Casos](#terms-cases). 557 | 558 | 559 | #### 2.1.2 Nunca Use Espaços 560 | 561 | Reforçando [2.1.1](#2.1.1), nunca use espaços. Os espaços podem fazer com que várias ferramentas de engenharia e processos em lote falhem. Idealmente, a raiz do seu projeto também não deve contém espaços e está localizada em algum lugar como `D:\Project` em vez de `C:\Users\My Name\My Documents\Unreal Projects`. 562 | 563 | 564 | #### 2.1.3 Nunca Use Caracteres Unicode e Outros Símbolos 565 | 566 | Se um dos personagens do jogo se chama 'Zoë', o nome da pasta deve ser `Zoe`. Caracteres Unicode podem ser piores do que [Espaços](#2.1.2) para a ferramenta de engenharia e algumas partes do UE4 que também não oferecem suporte a caracteres Unicode em caminhos. 567 | 568 | Relacionado a isso, se o seu projeto tiver [problemas inexplicáveis](https://answers.unrealengine.com/questions/101207/undefined.html) e o nome de usuário do seu computador tem um caractere Unicode (ou seja, seu nome é `Zoë`), qualquer projeto localizado na pasta `My Documents` sofrerá com esse problema. Freqüentemente, mover seu projeto para outra pasta como `D:\Project` corrigirá esses problemas. 569 | 570 | Usando outros caracteres fora `a-z`, `A-Z`, e `0-9` como `@`, `-`, `_`, `,`, `*`, e `#` também pode levar a problemas inesperados e difíceis de rastrear em outras plataformas, source controls e ferramentas de engenharia mais fracas. 571 | 572 | 573 | 574 | ### 2.2 Use Uma Pasta de Nível Superior Para Assets Específicos do Projeto 575 | 576 | Todos os assets de um projeto devem existir em uma pasta com o nome do projeto. Por exemplo, se o nome do seu projeto for 'Generic Shooter', _todo_ todo o seu conteúdo deve existir em `Content/GenericShooter`. 577 | 578 | > A pasta `Developers` não é para assets dos quais seu projeto depende e, portanto, não é específica do projeto. Consulte [Pastas de desenvolvedor] (# 2.3) para obter detalhes sobre isso. 579 | 580 | Existem várias razões para esta abordagem. 581 | 582 | 583 | #### 2.2.1 Sem Assets Globais 584 | 585 | Freqüentemente, nos guias de estilo de código está escrito que você não deve poluir o namespace global e isso segue o mesmo princípio. Quando assets podem existir fora de uma pasta de projeto, geralmente se torna muito mais difícil impor um layout de estrutura estrito, pois assets que não estão em uma pasta encorajam o mau comportamento de não ter que organiza-los. 586 | 587 | Todo asset deve ter um propósito, caso contrário, ele não pertence a um projeto. Se um asset é um teste experimental e não deve ser usado pelo projeto, deve ser colocado em uma pasta [`Developer`](#2.3). 588 | 589 | 590 | #### 2.2.2 Reduza Conflitos de Migração 591 | 592 | Ao trabalhar em vários projetos, é comum que uma equipe copie assets de um projeto para outro, caso tenham feito algo útil para ambos. Quando isso ocorre, a maneira mais fácil de realizar a cópia é usar a funcionalidade Migrar do navegador de conteúdo, pois ela copiará não apenas o asset selecionado, mas todas as suas dependências. 593 | 594 | Essas dependências podem facilmente causar problemas. Se os assets de dois projetos não tiverem uma pasta de nível superior e acontecerem de terem assets nomeados de forma semelhante ou já migrados anteriormente, uma nova migração pode apagar acidentalmente quaisquer alterações nos assets existentes. 595 | 596 | Esse também é o principal motivo pelo qual a equipe do Marketplace da Epic aplica a mesma política para assets enviados. 597 | 598 | Após uma migração, a fusão segura de assets pode ser feita usando a ferramenta 'Substituir referências' no navegador de conteúdo com a clareza adicional de assets não pertencentes à pasta de nível superior de um projeto e claramente aguardando uma fusão. Depois que os assets são mesclados e totalmente migrados, não deve haver outra pasta de nível superior em sua árvore de conteúdo. Este método é _100% _ garantido para tornar todas as migrações que ocorrerem completamente seguras. 599 | 600 | 601 | ##### 2.2.2e1 Exemplo de Master Material 602 | 603 | Por exemplo, digamos que você criou um Master Material em um projeto que gostaria de usar em outro projeto, então migrou esse asset. Se este asset não estiver em uma pasta de nível superior, pode ter um nome como `Content/MaterialLibrary/M_Master`. Se o projeto de destino ainda não tiver um Master Material, isso deve funcionar sem problemas. 604 | 605 | Conforme o trabalho em um ou ambos os projetos progride, seus respectivos Master Material podem ser alterados para serem adaptados para seus projetos específicos devido ao curso de desenvolvimento normal. 606 | 607 | O problema surge quando, por exemplo, um artista para um projeto criou um bom conjunto modular genérico de static meshes e alguém deseja incluir esse conjunto de static meshes no segundo projeto. Se o artista que criou os recursos usou Material Instances com base em `Content/MaterialLibrary/M_Master` conforme são instruídos, quando uma migração é realizada, há uma grande chance de conflito para o asset migrado anteriormente `Content/MaterialLibrary/M_Master`. 608 | 609 | Esse problema pode ser difícil de prever e de explicar. A pessoa que migra as static meshes pode não ser a mesma pessoa que está familiarizada com o desenvolvimento de ambos os Master Material do projeto e pode nem mesmo estar ciente de que as static meshes em questão dependem de Material Instances que, então, dependem do Master Material. A ferramenta Migrar requer que toda a cadeia de dependências funcione, no entanto, será obrigada a pegar `Content/MaterialLibrary/M_Master` quando ela copia esses assets para o outro projeto e sobrescrever o asset existente. 610 | 611 | É neste ponto que se os Master Materials para ambos os projetos forem incompatíveis de _qualquer maneira_, você corre o risco de quebrar possivelmente toda a biblioteca de Materials de um projeto, bem como quaisquer outras dependências que já possam ter sido migradas, simplesmente porque os assets não foram armazenados em uma pasta de nível superior. A simples migração de static meshes agora se torna uma tarefa muito ruim. 612 | 613 | 614 | #### 2.2.3 Amostras, Modelos e Conteúdos do Marketplace Estão Livres de Riscos 615 | 616 | Uma extensão para [2.2.2](#2.2.2), se um membro da equipe decidir adicionar conteúdo de amostra, arquivos de modelo ou assets que comprou no Marketplace, é garantido, desde que a pasta de nível superior do seu projeto tenha um nome exclusivo, que esses novos assets não interferirão em seu projeto. 617 | 618 | Você não pode confiar que o conteúdo do marketplace está em total conformidade com a [regra de pasta de nível superior] (# 2.2). Existem muitos assets que têm a maior parte de seu conteúdo em uma pasta de nível superior, mas também possuem Conteúdo de Amostra da Epic possivelmente modificados, bem como arquivos de nível poluindo a pasta global `Content`. 619 | 620 | Ao aderir a [2.2](#2.2), o pior conflito de marketplace que você pode ter é se dois assets de marketplace tiverem o mesmo Conteúdo de Amostra da Epic. Se todos os seus assets estiverem em uma pasta específica do projeto, incluindo conteúdo de amostra que você pode ter movido para a sua pasta, seu projeto nunca será quebrado. 621 | 622 | #### 2.2.4 DLC, Subprojetos e Patches São Facilmente Mantidos 623 | 624 | Se o seu projeto planeja lançar DLC ou tem vários subprojetos associados a ele que podem ser migrados ou simplesmente não preparados em uma construção, os assets relacionados a esses projetos devem ter sua própria pasta de conteúdo de nível superior separada. Isso torna muito mais fácil cozinhar DLC separados do conteúdo do projeto principal. Os subprojetos também podem ser migrados para dentro e para fora com o mínimo de esforço. Se você precisar alterar um material de um assets ou adicionar algum comportamento de substituição de asset muito específico em um patch, você pode facilmente colocar essas alterações em uma pasta de patch e trabalhar com segurança sem a chance de quebrar o projeto principal. 625 | 626 | 627 | 628 | ### 2.3 Use a Pasta Developers Para Testes Locais 629 | 630 | Durante o desenvolvimento de um projeto, é muito comum que os membros da equipe tenham uma espécie de 'sandbox' onde podem experimentar livremente sem arriscar o projeto principal. Como esse trabalho pode estar em andamento, esses membros da equipe podem querer colocar seus assets em um servidor de source control do projeto. Nem todas as equipes exigem o uso de pastas Developers, mas aquelas que as usam costumam ter um problema comum com assets enviados ao source control. 631 | 632 | É muito fácil para um membro da equipe usar acidentalmente assets que não estão prontos para uso, o que causará problemas quando esses assets forem removidos. Por exemplo, um artista pode estar iterando em um conjunto modular de static meshes e ainda trabalhando para obter o tamanho e o encaixe da grade corretos. Se um world designer ver esses assets na pasta principal do projeto, ele pode usá-los em um nível sem saber que podem estar sujeitos a mudanças e/ou remoções. Isso causa uma grande quantidade de retrabalho para todos na equipe resolverem. 633 | 634 | Se esses assets modulares fossem colocados em uma pasta de desenvolvedor, o world designer nunca deveria ter tido um motivo para usá-los e todo o problema nunca aconteceria. O navegador de conteúdo tem opções de exibição específicas que ocultam as pastas do desenvolvedor (elas ficam ocultas por padrão), tornando impossível o uso acidental de assets do desenvolvedor em uso normal. 635 | 636 | Assim que os recursos estiverem prontos para uso, o artista simplesmente precisa mover os recursos para a pasta específica do projeto e corrigir os redirecionadores. Isso é essencialmente 'promover' os assets do experimental para a produção. 637 | 638 | 639 | 640 | ### 2.4 Todo Arquivo de Mapa[*](#terms-level-map) Pertence a Uma Pasta Chamada Maps 641 | 642 | Os arquivos de mapa são incrivelmente especiais e é comum que cada projeto tenha seu próprio sistema de nomenclatura de mapa, especialmente se eles trabalharem com subníveis ou níveis de streaming. Não importa qual sistema de organização de mapas está em vigor para o projeto específico, todos os níveis devem pertencer a `/Content/Project/Maps`. 643 | 644 | Ser capaz de dizer a alguém para abrir um mapa específico sem ter que explicar onde ele está economiza muito tempo e melhora a 'qualidade de vida' em geral. É comum que os níveis estejam dentro de subpastas de `Maps`, tal como `Maps/Campaign1/` ou `Maps/Arenas`, mas o mais importante aqui é que todos eles existem dentro `/Content/Project/Maps`. 645 | 646 | Isso também simplifica o trabalho de cozinhar para os engenheiros. Combinar os níveis de um processo de compilação pode ser extremamente frustrante se eles tiverem que vasculhar pastas arbitrárias. Se os mapas de uma equipe estão todos em um só lugar, é muito mais difícil acidentalmente não preparar um mapa em uma construção. Ele também simplifica os scripts de construção de iluminação, bem como os processos de controle de qualidade. 647 | 648 | 649 | 650 | ### 2.5 Use uma Pasta `Core` Para Blueprints Críticos e Outros Assets 651 | 652 | Use a pasta`/Content/Project/Core` para assets que são absolutamente fundamentais para o funcionamento de um projeto. Por exemplo, `GameMode`, `Character`, `PlayerController`, `GameState`, `PlayerState`, base e os Blueprints relacionados devem residir aqui. 653 | 654 | Isso cria uma mensagem muito clara "não toque nestes" para os outros membros da equipe. Os que não são engenheiros devem ter muito poucos motivos para entrar na pasta `Core`. Seguindo um bom estilo de estrutura de código, os designers devem fazer seus ajustes de jogabilidade em classes filhas que expõem a funcionalidade. Os world designers devem usar Blueprints pré-fabricados em pastas designadas em vez de abusar potencialmente das classes base. 655 | 656 | Por exemplo, se o seu projeto requer "pickups" que podem ser colocados em um nível, deve existir uma classe de "pickup" base em `Core/Pickups` que define o comportamento básico para uma "pickup". Coletas específicas, como Health ou Ammo, devem existir em uma pasta como `/Content/Project/Placeables/Pickups/`. Os designers de jogos podem definir e ajustar opções nesta pasta da maneira que quiserem, mas não devem tocar `Core/Pickups` pois eles podem interromper involuntariamente "pickups" em todo o projeto. 657 | 658 | 659 | 660 | ### 2.6 Não Crie Pastas Chamadas `Assets` ou `AssetTypes` 661 | 662 | 663 | #### 2.6.1 Criar uma pasta chamada `Assets` é redundante. 664 | 665 | Todos assets são assets. 666 | 667 | 668 | #### 2.6.2 Criar uma pasta chamada `Meshes`, `Textures`, ou `Materials` é redundante. 669 | 670 | Todos os nomes de assets são nomeados com seu tipo de asset em mente. Essas pastas oferecem apenas informações redundantes e o uso dessas pastas pode ser facilmente substituído pelo sistema de filtragem robusto e fácil de usar que o Navegador de Conteúdo oferece. 671 | 672 | Quer apenas ver static mesh em `Environment/Rocks/`? Basta ativar o filtro Static Mesh. Se todos os assets forem nomeados corretamente, eles também serão classificados em ordem alfabética, independentemente dos prefixos. Quer visualizar static meshes e skeletal meshes? Basta ligar os dois filtros. Isso elimina a necessidade de selecionar duas pastas com `Control-Click` na visualização em árvore do navegador de conteúdo. 673 | 674 | > Isso também estende o nome do caminho completo de um asset para muito poucos benefícios. O prefixo `S_` para uma static mesh tem apenas dois caracteres, enquanto `Meshes/`tem sete caracteres. 675 | 676 | Não fazer isso também previne de alguém colocar uma static mesh ou uma textura em uma pasta `Materials`. 677 | 678 | 679 | 680 | ### 2.7 Conjunto de Assets Muito Grandes Tem Seu Próprio Layout de Pasta 681 | 682 | Isso pode ser visto como uma pseudo-exceção para [2.6](#2.6). 683 | 684 | Existem certos tipos de assets que possuem um grande volume de arquivos relacionados, onde cada asset tem uma finalidade única. Os dois mais comuns são assets de animação e áudio. Se você tiver mais de 15 desses assets que pertencem um ao outro, eles devem estar juntos. 685 | 686 | Por exemplo, as animações que são compartilhadas por vários personagens devem estar em `Characters/Common/Animations` e pode ter subpastas como `Locomotion` ou `Cinematic`. 687 | 688 | > Isso não se aplica a assets como texturas e materiais. É comum que uma pasta `Rochas` tenha uma grande quantidade de texturas se houver uma grande quantidade de pedras, no entanto, essas texturas geralmente estão relacionadas apenas a algumas pedras específicas e devem ser nomeadas apropriadamente. Mesmo que essas texturas sejam parte de uma [Biblioteca de Materials](#2.8). 689 | 690 | 691 | 692 | ### 2.8 `Biblioteca de Materials` 693 | 694 | Se o seu projeto faz uso de master materials, layered materials, ou qualquer forma de materiais reutilizáveis ou texturas que não pertençam a nenhum subconjunto de assets, esses assets devem estar localizados em `Content/Project/MaterialLibrary`. 695 | 696 | Desta forma materials 'global' têm um lugar e são facilmente localizados. 697 | 698 | > Isso também torna incrivelmente fácil aplicar uma política de 'use material instances only' dentro de um projeto. Se todos os artistas e assets deveriam estar usando instâncias de material, então os únicos assets materials regulares que deveriam existir estão dentro desta pasta. Você pode verificar isso facilmente procurando por base materials em qualquer pasta que não seja o `MaterialLibrary`. 699 | 700 | A `MaterialLibrary` não precisa consistir puramente em materials. Texturas de utilitários compartilhados, funções materiais e outras coisas dessa natureza devem ser armazenadas aqui também em pastas que indicam sua finalidade. Por exemplo, texturas de ruído genéricas devem estar localizadas em `MaterialLibrary/Utility`. 701 | 702 | Qualquer material de teste ou depuração deve estar dentro de `MaterialLibrary/Debug`. Isso permite que os materiais de depuração sejam facilmente retirados de um projeto antes do envio e torna incrivelmente aparente se os assets de produção os estão usando se forem mostrados erros de referência. 703 | 704 | 705 | 706 | ### 2.9 Sem Pastas Vazias 707 | 708 | Simplesmente não deve haver pastas vazias. Eles confundem o navegador de conteúdo. 709 | 710 | Se você descobrir que o navegador de conteúdo tem uma pasta vazia que não pode ser excluída, faça o seguinte: 711 | 1. Certifique-se de usar o controle de origem. 712 | 1. Execute imediatamente Fix Up Redirectors em seu projeto. 713 | 1. Navegue até a pasta no disco e exclua os assets dentro dela. 714 | 1. Feche o editor. 715 | 1. Certifique-se de que seu estado de source control está sincronizado (ou seja, se estiver usando Perforce, execute um Reconcile Offline Work em seu diretório de conteúdo) 716 | 1. Abra o editor. Confirme se tudo ainda está funcionando conforme o esperado. Caso contrário, reverta, descubra o que deu errado e tente novamente. 717 | 1. Certifique-se de que a pasta já foi removida. 718 | 1. Envie as alterações para o source control. 719 | 720 | **[⬆ Voltar ao topo](#table-of-contents)** 721 | 722 | 723 | 724 | 725 | ## 3. Blueprints 726 | 727 | Esta seção se concentrará nas classes do Blueprint e em seus aspectos internos. Quando possível, as regras de estilo estão em conformidade com [Epic's Coding Standard](https://docs.unrealengine.com/latest/INT/Programming/Development/CodingStandard). 728 | 729 | Lembre-se: Blueprinting comporta mal os erros, cuidado! (Frase por [KorkuVeren](http://github.com/KorkuVeren)) 730 | 731 | ### Sections 732 | 733 | > 3.1 [Compilando](#bp-compiling) 734 | 735 | > 3.2 [Variáveis](#bp-vars) 736 | 737 | > 3.3 [Funções](#bp-functions) 738 | 739 | > 3.4 [Gráficos](#bp-graphs) 740 | 741 | 742 | 743 | ### 3.1 Compilando 744 | 745 | Todos os blueprints devem ser compilados com nenhum aviso e nenhum erro. Você deve corrigir os avisos e erros do blueprint imediatamente, pois eles podem rapidamente se transformar em um comportamento inesperado muito assustador. 746 | 747 | *Não* envie projetos corrompidos ao source control. Se você deve armazená-los no source control, arquive-os. 748 | 749 | Projetos corrompidos podem causar problemas que se manifestam de outras maneiras, como referências quebradas, comportamento inesperado, falhas de cozimento e recompilação desnecessária frequente. Um projeto quebrado tem o poder de quebrar todo o seu jogo. 750 | 751 | 752 | 753 | ### 3.2 Variáveis 754 | 755 | As palavras `variable` e `property` podem ser usadas alternadamente. 756 | 757 | #### Seções 758 | 759 | > 3.2.1 [Nomeação](#bp-vars) 760 | 761 | > 3.2.2 [Editável](#bp-vars-editable) 762 | 763 | > 3.2.3 [Categorias](#bp-vars-categories) 764 | 765 | > 3.2.4 [Acesso](#bp-vars-access) 766 | 767 | > 3.2.5 [Avançado](#bp-vars-advanced) 768 | 769 | > 3.2.6 [Transiente](#bp-vars-transient) 770 | 771 | > 3.2.7 [Config](#bp-vars-config) 772 | 773 | 774 | 775 | #### 3.2.1 Nomenclatura 776 | 777 | 778 | 779 | ##### 3.2.1.1 Substantivos 780 | 781 | Todos os nomes de variáveis que não são booleans devem ser substantivos claros, não ambíguos e descritivos. 782 | 783 | 784 | 785 | ##### 3.2.1.2 PascalCase 786 | 787 | Todas as variáveis não booleanas devem estar na forma de [PascalCase](#terms-cases). 788 | 789 | 790 | ###### 3.2.1.2e Exemplos: 791 | 792 | * `Score` 793 | * `Kills` 794 | * `TargetPlayer` 795 | * `Range` 796 | * `CrosshairColor` 797 | * `AbilityID` 798 | 799 | 800 | 801 | ##### 3.2.1.3 Prefix `b` Para Boolean 802 | 803 | Todos os booleans devem ser nomeados em PascalCase, mas prefixados com uma minúscula `b`. 804 | 805 | Exemplo: Use `bDead` e `bEvil`, **não use** `Dead` ou `Evil`. 806 | 807 | Editores Blueprint UE4 sabem não colocar o `b` em exibições user-friendly da variável. 808 | 809 | 810 | 811 | ##### 3.2.1.4 Nomes de Booleans 812 | 813 | 814 | ###### 3.2.1.4.1 Informações Gerais e Condições Independentes 815 | 816 | Todos os booleans devem ser nomeados como adjetivos descritivos, quando possível, se representarem informações gerais. Não inclua palavras que expressem a variável como uma pergunta, como `Is`. Isso é reservado para funções. 817 | 818 | Exemplo: Use `bDead` e `bHostile` **não use** `bIsDead` ou `bIsHostile`. 819 | 820 | Tente não usar verbos como `bRunning`. Os verbos tendem a levar a estados complexos. 821 | 822 | 823 | ###### 3.2.1.4.2 Condições Complexas 824 | 825 | Não use booleans para representar condições complexas e/ou dependentes. Isso torna a adição e remoção das condições complexas mais difíceis de ler. Em vez disso, use uma enumeração. 826 | 827 | Exemplo: Ao definir uma arma, **não** use `bReloading` e `bEquipping` se uma arma não pode recarregar e ser equipada. Defina uma enumeração chamada `EWeaponState` e usar uma variável com este tipo chamada `WeaponState` em vez disso. Isso torna muito mais fácil adicionar novos estados às armas. 828 | 829 | Exemplo: **Não** use `bRunning` se você também precisa de `bWalking` ou `bSprinting`. Isso deve ser definido como uma enumeração com nomes de estado claramente definidos. 830 | 831 | 832 | 833 | ##### 3.2.1.5 Contexto Deve Ser Considerado 834 | 835 | Todos os nomes de variáveis não devem ser redundantes com seu contexto, pois todas as referências de variáveis no Blueprint sempre terão contexto. 836 | 837 | 838 | ###### 3.2.1.5e Exemplos: 839 | 840 | Considere um Blueprint chamado `BP_PlayerCharacter`. 841 | 842 | **Ruim** 843 | 844 | * `PlayerScore` 845 | * `PlayerKills` 846 | * `MyTargetPlayer` 847 | * `MyCharacterName` 848 | * `CharacterSkills` 849 | * `ChosenCharacterSkin` 850 | 851 | Todas essas variáveis são nomeadas de forma redundante. Está implícito que a variável pertence ao `BP_PlayerCharacter` porque é o `BP_PlayerCharacter` que está definindo essas variáveis. 852 | 853 | **Bom** 854 | 855 | * `Score` 856 | * `Kills` 857 | * `TargetPlayer` 858 | * `Name` 859 | * `Skills` 860 | * `Skin` 861 | 862 | 863 | 864 | ##### 3.2.1.6 _Não_ Inclua Nomes de Tipo Atômico 865 | 866 | Variáveis atômicas ou primitivas são variáveis que representam dados em sua forma mais simples, como booleans, integers, floats e enumerações. 867 | 868 | Strings e vectors são considerados atômicos em termos de estilo ao trabalhar com Blueprints, no entanto, eles não são tecnicamente atômicos. 869 | 870 | > Enquanto vectors consiste de três floats, vectors muitas vezes podem ser manipulados como um todo, assim como rotators. 871 | 872 | > _Não_ considere Text Variables como atômicas, elas estão escondendo a funcionalidade de localização. O tipo atômico de uma string de caracteres é `String`, não `Text`. 873 | 874 | Variáveis atômicas não devem ter seu nome de tipo em seu nome. 875 | 876 | Exemplo: Use `Score`, `Kills`, e `Description` **não use** `ScoreFloat`, `FloatKills`, `DescriptionString`. 877 | 878 | A única exceção a esta regra é quando uma variável representa 'um número de' algo a ser contado _e_ quando usar um nome difícil de ler sem um tipo de variável. 879 | 880 | Exemplo: Um gerador de cerca precisa gerar um número X de postes. Armazene X em `NumPosts` ou `PostsCount` em vez de `Posts` como `Posts` pode potencialmente ser lido como um Array de um tipo de variável chamado `Post`. 881 | 882 | 883 | 884 | ##### 3.2.1.7 Inclua Nomes de Tipo Não Atômico 885 | 886 | Variáveis não atômicas ou complexas são variáveis que representam dados como uma coleção de variáveis atômicas. Structs, Classes, Interfaces, e primitivas with com comportamento oculto, como `Text` e `Name` todos se qualificam sob esta regra. 887 | 888 | > Enquanto um Array de um tipo de variável atômica é uma lista de variáveis, Arrays não altera a 'atomicidade' de um tipo de variável. 889 | 890 | Essas variáveis devem incluir seu nome de tipo, ainda considerando seu contexto. 891 | 892 | Se uma classe possui uma instância de uma variável complexa, e.x. se um `BP_PlayerCharacter` possui um `BP_Hat`, deve ser armazenado como o tipo de variável, sem nenhuma modificação de nome. 893 | 894 | Exemplo: Use `Hat`, `Flag`, e `Ability` **não use** `MyHat`, `MyFlag`, e `PlayerAbility`. 895 | 896 | Se uma classe não possui o valor que uma variável complexa representa, você deve usar um substantivo junto com o tipo de variável. 897 | 898 | Exemplo: Se um `BP_Turret` tem a capacidade de mirar um `BP_PlayerCharacter`, deve armazenar seu alvo como `TargetPlayer` como quando no contexto de `BP_Turret` deve ficar claro que é uma referência a outro tipo de variável complexa que não possui. 899 | 900 | 901 | 902 | 903 | ##### 3.2.1.8 Arrays 904 | 905 | Arrays segue as mesmas regras de nomenclatura acima, mas deve ser nomeado como um substantivo no plural. 906 | 907 | Exemplo: Use `Targets`, `Hats`, e `EnemyPlayers`, **não use** `TargetList`, `HatArray`, `EnemyPlayerArray`. 908 | 909 | 910 | 911 | 912 | #### 3.2.2 Variáveis Editáveis 913 | 914 | Todas as variáveis que são seguras para alterar o valor de para configurar o comportamento de um blueprint devem ser marcadas como `Editable`. 915 | 916 | Por outro lado, todas as variáveis que não são seguras para alteração ou não devem ser expostas aos designers _não_ devem ser marcadas como editáveis, a menos que por razões de engenharia a variável deva ser marcada como `Expose On Spawn`. 917 | 918 | Não marque variáveis arbitrariamente como `Editable`. 919 | 920 | 921 | 922 | ##### 3.2.2.1 Tooltips 923 | 924 | Todas variáveis `Editable`, incluindo aqueles marcados como editáveis, apenas para que possam ser marcados como `Expose On Spawn`, deve ter uma descrição em seus campos de `Tooltip` que explique como a alteração desse valor afeta o comportamento do blueprint. 925 | 926 | 927 | 928 | ##### 3.2.2.2 Sliders e Intervalos de Valor 929 | 930 | Todas variáveis `Editable` deve fazer uso de um slider e um intervalo de valor se houver um valor para o qual uma variável _não_ deve ser definida. 931 | 932 | Exemplo: Um blueprint que gera postes de cerca pode ter uma variável editável chamada `PostsCount` e um valor de -1 não faria nenhum sentido. Use os campos de intervalo para marcar 0 como o mínimo. 933 | 934 | Se uma variável editável é usada em um Construction Script, deve ter um "Slider Range" razoável definido para que alguém não possa acidentalmente atribuir a ele um grande valor que poderia travar o editor. 935 | 936 | Um "Value Range" só precisa ser definido se os limites de um valor forem conhecidos. Enquanto um "Slider Range" evita entradas acidentais de um grande número, um indefinido "Value Range" permite que um usuário especifique um valor fora do "Slider Range" que pode ser considerado 'perigoso', mas ainda válido. 937 | 938 | 939 | 940 | #### 3.2.3 Categorias 941 | 942 | Se uma classe tem apenas um pequeno número de variáveis, as categorias não são obrigatórias. 943 | 944 | Se uma class tem uma quantidade moderada de variáveis (5-10), todas variáveis `Editable` deve ter uma categoria não padrão atribuída. Uma categoria comum é `Config`. 945 | 946 | Se uma class tem uma grande quantidade de variáveis, todas variáveis `Editable` deve ser categorizado em subcategorias usando a categoria `Config` como a categoria base. Variáveis não editáveis devem ser categorizadas em categorias descritivas que descrevem seu uso. 947 | 948 | > Você pode definir subcategorias usando a barra vertical `|`, e.x. `Config | Animations`. 949 | 950 | Exemplo: Um conjunto de variáveis de classe de arma pode ser organizado como: 951 | 952 | |-- Config 953 | | |-- Animations 954 | | |-- Effects 955 | | |-- Audio 956 | | |-- Recoil 957 | | |-- Timings 958 | |-- Animations 959 | |-- State 960 | |-- Visuals 961 | 962 | 963 | 964 | #### 3.2.4 Nível de acesso variável 965 | 966 | Em C ++, as variáveis têm um conceito de nível de acesso. Público significa que qualquer código fora da classe pode acessar a variável. Protegido significa que apenas a classe e quaisquer classes filhas podem acessar essa variável internamente. Privado significa que apenas esta classe e nenhuma classe filha pode acessar esta variável. 967 | 968 | Blueprints atualmente não tem um conceito definido de acesso protegido. 969 | 970 | Trate a variável `Editable` como variáveis públicas. Trate as variáveis não editáveis como variáveis protegidas. 971 | 972 | 973 | 974 | ##### 3.2.4.1 Variáveis Privadas 975 | 976 | A menos que se saiba que uma variável só deve ser acessada dentro da classe em que está definida e nunca em uma classe filha, não marque as variáveis como privadas. Até que as variáveis possam ser marcadas `protected`, reserve particular para quando você tiver certeza absoluta de que deseja restringir o uso de classes filhas. 977 | 978 | 979 | 980 | #### 3.2.5 Display Avançado 981 | 982 | Se uma variável deve ser editável, mas muitas vezes intocada, marque-a como `Advanced Display`. Isso torna a variável oculta, a menos que a seta de exibição avançada seja clicada. 983 | 984 | Para encontrar a opção `Advanced Display`, ela é listada como uma variável avançada exibida na lista de detalhes da variável. 985 | 986 | 987 | 988 | #### 3.2.6 Variáveis Transientes 989 | 990 | Variáveis transientes são variáveis que não precisam ter seu valor salvo e carregado, e possuem um valor inicial igual a zero ou nulo. Isso é útil para referências a outros objetos e atores cujo valor não é conhecido até o tempo de execução. Isso evita que o editor salve uma referência a ele e acelera o salvamento e o carregamento da classe de blueprint. 991 | 992 | Por causa disso, todas as variáveis transientes sempre devem ser inicializadas como zero ou nulas. Fazer o contrário resultaria em erros difíceis de depurar. 993 | 994 | 995 | 996 | #### 3.2.8 Variáveis de configuração 997 | 998 | Não use a flag `Config Variable`. Isso torna mais difícil para os designers controlar o comportamento do blueprint. Variáveis de configuração só devem ser usadas em C ++ para variáveis raramente alteradas. Pense neles como variáveis `Advanced Advanced Display`. 999 | 1000 | 1001 | 1002 | ### 3.3 Functions, Events, e Event Dispatchers 1003 | 1004 | Esta seção descreve como você deve criar functions, events, e event dispatchers. Tudo o que se aplica a funções também se aplica a events, salvo indicação contrária. 1005 | 1006 | 1007 | 1008 | #### 3.3.1 Nomenclatura de função 1009 | 1010 | A nomenclatura de functions, events, e event dispatchers são extremamente importante. Com base apenas no nome, certas suposições podem ser feitas sobre as funções. Por exemplo: 1011 | 1012 | * É uma função "pure"? 1013 | * Está buscando informações de estado? 1014 | * É um handler? 1015 | * É um RPC? 1016 | * Qual é seu propósito? 1017 | 1018 | Essas perguntas e muito mais podem ser respondidas quando as funções são nomeadas apropriadamente. 1019 | 1020 | 1021 | 1022 | #### 3.3.1.1 Todas as Funções Devem Ser Verbos 1023 | 1024 | Todas as funções e events realizam alguma forma de ação, seja para obter informações, calcular dados ou fazer algo explodir. Portanto, todas as funções devem começar com verbos. Eles devem ser redigidos no tempo presente sempre que possível. Eles também devem ter algum contexto sobre o que estão fazendo. 1025 | 1026 | Funções `OnRep`, event handlers, e event dispatchers são uma exceção a esta regra. 1027 | 1028 | Bons exemplos: 1029 | 1030 | * `Fire` - Bom exemplo se estiver em uma classe de Personagem/Arma, pois tem contexto. Ruim se estiver em um Barril / Gramado / qualquer classe ambígua. 1031 | * `Jump` - Bom exemplo se em uma classe de Personagem, caso contrário, precisa de contexto. 1032 | * `Explode` 1033 | * `ReceiveMessage` 1034 | * `SortPlayerArray` 1035 | * `GetArmOffset` 1036 | * `GetCoordinates` 1037 | * `UpdateTransforms` 1038 | * `EnableBigHeadMode` 1039 | * `IsEnemy` - ["Is" é um verbo.](http://writingexplained.org/is-is-a-verb) 1040 | 1041 | Maus exemplos: 1042 | 1043 | * `Dead` - Está morto? Vai morrer? 1044 | * `Rock` 1045 | * `ProcessData` - Ambíguas, essas palavras não significam nada. 1046 | * `PlayerState` - Os substantivos são ambíguos. 1047 | * `Color` - Verbo sem contexto ou substantivo ambíguo. 1048 | 1049 | 1050 | 1051 | #### 3.3.1.2 Funções Com Propriedade "RepNotify" Sempre `OnRep_Variable` 1052 | 1053 | Todas as funções replicadas com variáveis de notificação devem ter o formato `OnRep_Variable`. Isso é forçado pelo editor Blueprint. Se você está escrevendo um C ++ `OnRep` no entanto, ele também deve seguir esta convenção ao expô-lo para Blueprints. 1054 | 1055 | 1056 | 1057 | #### 3.3.1.3 Funções de Informação Que Retornam Bool Devem Fazer Perguntas 1058 | 1059 | Ao escrever uma função que não altera o estado ou modifica qualquer objeto e é puramente para: obter informações, estado ou calcular um valor sim/não. Ela deve fazer uma pergunta. Isso também deve seguir [a regra do verbo](#bp-funcs-naming-verbs). 1060 | 1061 | Isso é extremamente importante, pois se uma pergunta não for feita, pode-se presumir que a função executa uma ação e está retornando se essa ação foi bem-sucedida. 1062 | 1063 | Bons exemplos: 1064 | 1065 | * `IsDead` 1066 | * `IsOnFire` 1067 | * `IsAlive` 1068 | * `IsSpeaking` 1069 | * `IsHavingAnExistentialCrisis` 1070 | * `IsVisible` 1071 | * `HasWeapon` - ["Has" é um verbo.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html) 1072 | * `WasCharging` - ["Was" é pretérito de "be".](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html) Use "was" quando se refere a 'quadro anterior' ou 'estado anterior'. 1073 | * `CanReload` - ["Can" é um verbo.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html) 1074 | 1075 | Maus exemplos: 1076 | 1077 | * `Fire` - Está em chamas? Vai atirar? Atire? 1078 | * `OnFire` - Pode ser confundido com o event dispatcher para disparo. 1079 | * `Dead` - Está morto? Vai morrer? 1080 | * `Visibility` - É visível? Definir visibilidade? Uma descrição das condições de vôo? 1081 | 1082 | 1083 | 1084 | #### 3.3.1.4 Event Handlers e Dispatchers Deve Começar Com `On` 1085 | 1086 | Qualquer função que lida com um event ou despacha um event deve começar com `On` e continue a seguir [a regra do verbo](#bp-funcs-naming-verbs). O verbo pode mover-se para o final, no entanto, se o tempo passado for melhor lido. 1087 | 1088 | [Colocações](http://dictionary.cambridge.org/us/grammar/british-grammar/about-words-clauses-and-sentences/collocation) da palavra `On` estão isentos de seguir a regra do verbo. 1089 | 1090 | `Handle` não é permitido. É 'irreal' usar `On` ao invés de `Handle`, enquanto outras estruturas podem preferir usar `Handle` ao invés de `On`. 1091 | 1092 | Bons exemplos: 1093 | 1094 | * `OnDeath` - Colocação comum em jogos 1095 | * `OnPickup` 1096 | * `OnReceiveMessage` 1097 | * `OnMessageRecieved` 1098 | * `OnTargetChanged` 1099 | * `OnClick` 1100 | * `OnLeave` 1101 | 1102 | Maus exemplos: 1103 | 1104 | * `OnData` 1105 | * `OnTarget` 1106 | * `HandleMessage` 1107 | * `HandleDeath` 1108 | 1109 | 1110 | 1111 | #### 3.3.1.5 Chamadas de Procedimento Remoto (RPC) Devem Ser Prefixadas com Destino 1112 | 1113 | Sempre que um RPC é criado, deve ser prefixado com um `Server`, `Client`, ou `Multicast`. Sem exceções. 1114 | 1115 | Após o prefixo, siga todas as outras regras relacionadas à nomenclatura de funções. 1116 | 1117 | Bons exemplos: 1118 | 1119 | * `ServerFireWeapon` 1120 | * `ClientNotifyDeath` 1121 | * `MulticastSpawnTracerEffect` 1122 | 1123 | Maus exemplos: 1124 | 1125 | * `FireWeapon` - Não indica que seja algum tipo de RPC. 1126 | * `ServerClientBroadcast` - Confuso. 1127 | * `AllNotifyDeath` - Use `Multicast`, nunca `All`. 1128 | * `ClientWeapon` - Sem verb, ambíguo. 1129 | 1130 | 1131 | 1132 | 1133 | #### 3.3.2 Todas as Funções Devem Ter "Return Nodes" 1134 | 1135 | Todas as funções devem ter return nodes, sem exceções. 1136 | 1137 | Return nodes significam que uma função concluiu sua execução. Como os projetos podem ser preenchidos com `Sequence`, `ForLoopWithBreak`, e reroute nodes reversos, fluxo de execução explícito é importante para leitura, manutenção e depuração mais fáceis dos mesmos. 1138 | 1139 | O compilador Blueprint é capaz de seguir o fluxo de execução e irá avisá-lo se houver um branch de seu código com um retorno não tratado ou fluxo incorreto se você usar return nodes. 1140 | 1141 | Em situações como quando um programador pode adicionar um alfinete a um Sequence node ou adicionar lógica após a conclusão de um "loop for", mas a iteração do loop pode retornar mais cedo, o que geralmente pode resultar em um erro acidental no fluxo de código. Os avisos do compilador Blueprint alertarão a todos sobre esses problemas imediatamente. 1142 | 1143 | 1144 | 1145 | #### 3.3.3 Nenhuma Função Deve Ter Mais de 50 Nós 1146 | 1147 | Simplesmente, nenhuma função deve ter mais de 50 nós. Qualquer função desse tamanho deve ser dividida em funções menores para facilitar a leitura e manutenção. 1148 | 1149 | Os seguintes nós não são contados, pois são considerados como não aumentando a complexidade da função: 1150 | 1151 | * Comentários 1152 | * Route 1153 | * Cast 1154 | * Obtendo uma Variable 1155 | * Quebrando um Struct 1156 | * Funções Entry 1157 | * Self 1158 | 1159 | 1160 | 1161 | #### 3.3.4 Todas As Funções Públicas Devem Ter Uma Descrição 1162 | 1163 | Esta regra se aplica mais a blueprints públicas ou do marketplace, para que outras pessoas possam navegar e consumir sua API de blueprint com mais facilidade. 1164 | 1165 | Simplesmente, qualquer função que tenha um especificador de acesso de Public deve ter sua descrição preenchida. 1166 | 1167 | 1168 | 1169 | #### 3.3.5 Todas Funções de Plugin 'Static' e `BlueprintCallable` Personalizadas Deve Ser Categorizado Pelo Nome do Plugin 1170 | 1171 | Se o seu projeto inclui um plugin que define funções `static` `BlueprintCallable`, ele devem ter sua categoria definida para o nome do plugin ou uma categoria de subconjunto do nome do plugin. 1172 | 1173 | Por exemplo, `Zed Camera Interface` ou `Zed Camera Interface | Image Capturing`. 1174 | 1175 | 1176 | 1177 | ### 3.4 Gráficos Blueprint 1178 | 1179 | Esta seção cobre coisas que se aplicam a todos os gráficos do Blueprint. 1180 | 1181 | 1182 | 1183 | #### 3.4.1 Sem "Espaguete" 1184 | 1185 | Os fios devem ter começo e fim claros. Você nunca deve ter que desembaraçar mentalmente os fios para dar sentido a um gráfico. Muitas das seções a seguir são dedicadas à redução do "espaguete". 1186 | 1187 | 1188 | 1189 | #### 3.4.2 Alinhe Fios, Não Nodes 1190 | 1191 | Sempre alinhe os fios, não os nodes. Você nem sempre pode controlar o tamanho e a localização do pino em um node, mas você sempre pode controlar a localização de um node e, assim, controlar os fios. Fios retos fornecem fluxo linear claro. Fios ondulados desgastam muito a mente. Você pode endireitar os fios usando o comando "Straighten Connections" com os nodes BP selecionados. Atalho: Q 1192 | 1193 | Bom exemplo: os topos dos nodes são escalonados para manter uma linha executiva branca perfeitamente reta. 1194 | ![Alinhado Por Fios](https://raw.githubusercontent.com/Allar/ue5-style-guide/main/images/bp-graphs-align-wires-good.png "Alinhado Por Fios") 1195 | 1196 | Mau exemplo: Os topos dos nodes são alinhados, criando uma linha executiva branca ondulada. 1197 | ![Ruim](https://raw.githubusercontent.com/Allar/ue5-style-guide/main/images/bp-graphs-align-wires-bad.png "Ondulado") 1198 | 1199 | Exemplo aceitável: Certos nodes podem não cooperar, não importa como você usa as ferramentas de alinhamento. Nessa situação, tente minimizar a oscilação trazendo o node para mais perto. 1200 | ![Aceitável](https://raw.githubusercontent.com/Allar/ue5-style-guide/main/images/bp-graphs-align-wires-acceptable.png "Aceitável") 1201 | 1202 | 1203 | 1204 | #### 3.4.3 Linhas de Execução Branca São De Alta Prioridade 1205 | 1206 | Se você alguma vez tiver que decidir entre endireitar uma linha executiva branca linear ou endireitar linhas de dados de algum tipo, sempre endireite a linha executiva branca. 1207 | 1208 | 1209 | 1210 | #### 3.4.4 Os Gráficos Devem Ser Comentadas Razoavelmente 1211 | 1212 | Os blocos de nodes devem ser incluídos em comentários que descrevam seu comportamento de nível superior. Embora cada função deva ser bem nomeada para que cada node individual seja facilmente legível e compreensível, grupos de nodes que contribuem para um propósito devem ter seu propósito descrito em um bloco de comentário. Se uma função não tiver muitos blocos de nodes e ficar claro que os nodes estão servindo a um propósito direto no objetivo da função, eles não precisam ser comentados, pois o nome e a descrição da função devem ser suficientes. 1213 | 1214 | 1215 | 1216 | #### 3.4.5 Os Gráficos Devem Lidar Com Error de Casting Onde Apropriado 1217 | 1218 | Se uma função ou evento presumir que uma conversão sempre é bem-sucedida, ele deve relatar apropriadamente uma falha na lógica se o casting falhar. Isso permite que outras pessoas saibam por que algo que "deveria funcionar" não funciona. Uma função também deve tentar uma recuperação normal após um cast com falha se for conhecido que a referência que está sendo lançada pode falhar durante o cast. 1219 | 1220 | Isso não significa que cada node de cast deve ter sua falha tratada. Em muitos casos, especialmente eventos relacionados a coisas como colisões, espera-se que o fluxo de execução termine silenciosamente em um cast com falha. 1221 | 1222 | 1223 | 1224 | #### 3.4.6 Os Gráficos Não Devem Ter Nodes Pendentes / Soltos / Mortos 1225 | 1226 | Todos os nodes em todos os gráficos do blueprint devem ter um propósito. Você não deve deixar nodes de blueprint pendurados por aí que não têm propósito ou não são executados. 1227 | 1228 | **[⬆ Voltar ao topo](#table-of-contents)** 1229 | 1230 | 1231 | 1232 | 1233 | 1234 | ## 4. Static Meshes 1235 | 1236 | Esta seção se concentrará em assets Static Mesh e seus internos. 1237 | 1238 | ### Seções 1239 | 1240 | > 4.1 [UVs](#s-uvs) 1241 | 1242 | > 4.2 [LODs](#s-lods) 1243 | 1244 | > 4.3 [Encaixe Modular Sem Socket](#s-modular-snapping) 1245 | 1246 | > 4.4 [Deve Ter Colisão](#s-collision) 1247 | 1248 | > 4.5 [Escala Correta](#s-scaled) 1249 | 1250 | 1251 | 1252 | ### 4.1 UVs Static Mesh 1253 | 1254 | Se o Linter está reportando maus UVs e você não consegue rastreá-los, abra o arquivo resultante `.log` no seu projeto `Saved/Logs` para obter detalhes exatos sobre o motivo da falha. Espero que incluam essas mensagens no relatório Lint no futuro. 1255 | 1256 | 1257 | 1258 | #### 4.1.1 Todos Meshes Devem Ter UVs 1259 | 1260 | Bem simples. Todos os meshes, independentemente de como devem ser usadas, não devem ter UVs faltando. 1261 | 1262 | 1263 | 1264 | #### 4.1.2 Todos Meshes Não deve ter sobreposição UVs de Lightmaps 1265 | 1266 | Bem simples. Todas os meshes, independentemente de como devem ser usadas, devem ter UVs válidos sem sobreposição. 1267 | 1268 | 1269 | 1270 | ### 4.2 LODs Devem Ser Configurados Corretamente 1271 | 1272 | Esta é uma verificação subjetiva por projeto, mas como regra geral, qualquer meshe que pode ser vista em distâncias variáveis deve ter LODs adequados. 1273 | 1274 | 1275 | 1276 | ### 4.3 Assests Modulares Sem Soquete Devem Se Encaixar na Grade de Forma Limpa 1277 | 1278 | Esta é uma verificação subjetiva por asset, no entanto, quaisquer assets modulares sem soquete devem se encaixar perfeitamente com base nas configurações de grade do projeto. 1279 | 1280 | Fica a critério do projeto se encaixar com base em uma grade de 2 ou em uma grade de base 10. No entanto, se você estiver criando assets modulares sem soquete para o marketplace, o requisito da Epic é que eles se encaixem perfeitamente quando a grade for configurada para 10 unidades ou mais. 1281 | 1282 | 1283 | 1284 | ### 4.4 Todos Meshes Devem Ter Colisão 1285 | 1286 | Independentemente de um assets ser usado para colisão em um level, todos os meshes devem ter a colisão adequada definida. Isso ajuda o mecanismo com coisas como cálculos de limites, oclusão e iluminação. A colisão também deve ser bem formada para o asset. 1287 | 1288 | 1289 | 1290 | ### 4.5 Todos Meshes Deve Ser Dimensionado Corretamente 1291 | 1292 | Esta é uma verificação subjetiva por projeto; no entanto, todos os assets devem ser dimensionados corretamente para o projeto. Os level designers ou autores de blueprint não devem ter que ajustar a escala dos meshes para que sejam confirmadas no editor. Redimencionar meshes na engine deve se tratadas como uma substituição de escala, não uma correção de escala. 1293 | 1294 | **[⬆ Voltar ao topo](#table-of-contents)** 1295 | 1296 | 1297 | 1298 | 1299 | 1300 | ## 5. Niagara 1301 | 1302 | Esta seção se concentrará em assets Niagara e seus internos. 1303 | 1304 | ### Seções 1305 | 1306 | > 5.1 [Regras de Nomenclatura](#ng-rules) 1307 | 1308 | 1309 | 1310 | ### 5.1 Sem Espaços, Nunca 1311 | 1312 | Conforme mencionado em [00.1 Identificadores Proibidos](#00), espaços e todos os caracteres de espaço em branco são proibidos em identificadores. Isso é especialmente verdadeiro para os sistemas Niagara, pois torna o trabalho com as coisas significativamente mais difícil, senão impossível, ao trabalhar com HLSL ou outros meios de script dentro do Niagara e ao tentar fazer referência a um identificador. 1313 | 1314 | (Contribuição original por [@dunenkoff](https://github.com/Allar/ue5-style-guide/issues/58)) 1315 | 1316 | 1317 | **[⬆ Voltar ao topo](#table-of-contents)** 1318 | 1319 | 1320 | 1321 | 1322 | 1323 | ## 6. Levels / Maps 1324 | 1325 | [Veja a Nota de Terminologia](#terms-level-map) sobre "levels" vs "maps". 1326 | 1327 | Esta seção se concentrará em assets de Level e seus internos. 1328 | 1329 | ### Seções 1330 | 1331 | > 6.1 [Sem Erros ou Avisos](#levels-no-errors-or-warnings) 1332 | 1333 | > 6.2 [A Iluminação Deve Ser Construída](#levels-lighting-should-be-built) 1334 | 1335 | > 6.3 [Nenhum "Z Fighting" Visível ao Jogador](#evels-no-visible-z-fighting) 1336 | 1337 | > 6.4 [Regras Específicas de Marketplace](#evels-levels-mp-rules) 1338 | 1339 | 1340 | 1341 | ### 6.1 Sem Erros ou Avisos 1342 | 1343 | Todos os levels devem carregar sem erros ou avisos. Se um level for carregado com erros ou avisos, eles devem ser corrigidos imediatamente para evitar problemas em cascata. 1344 | 1345 | Você pode executar uma verificação de mapa em um level aberto no editor usando o comando de console "map check". 1346 | 1347 | Observação: o Linter é ainda mais rígido nisso do que o editor atualmente, e detectará erros de carregamento que o editor resolverá sozinho. 1348 | 1349 | 1350 | 1351 | ### 6.2 A Iluminação Deve Ser Construída 1352 | 1353 | É normal que, durante o desenvolvimento, os levels ocasionalmente não tenham iluminação. Ao fazer um teste/building interna/de envio ou qualquer building a ser distribuída, no entanto, a iluminação deve sempre ser construída. 1354 | 1355 | 1356 | 1357 | ### 6.3 No Player Visible Z Fighting 1358 | 1359 | Nenhum level deve ter [z-fighting](https://en.wikipedia.org/wiki/Z-fighting) em todas as áreas visíveis ao jogador. 1360 | 1361 | 1362 | 1363 | ### 6.4 Regras Específicas de Marketplace 1364 | 1365 | Se um projeto for vendido no Marketplace UE4, deve seguir essas regras. 1366 | 1367 | 1368 | 1369 | ### 6.4.1 Level de Overview 1370 | 1371 | Se o seu projeto contém assets que devem ser visualizados ou demonstrados, você deve ter um mapa dentro do seu projeto que contém o nome "Overview". 1372 | 1373 | Esse mapa overview, se estiver visualizando assets, deve ser configurado de acordo com [As Diretrizes da Epic](http://help.epicgames.com/customer/en/portal/articles/2592186-marketplace-submission-guidelines-preparing-your-assets#Required%20Levels%20and%20Maps). 1374 | 1375 | Por exemplo, `InteractionComponent_Overview`. 1376 | 1377 | 1378 | 1379 | ### 6.4.2 Level Demo 1380 | 1381 | Se o seu projeto contém assets que devem ser demonstrados ou vêm com algum tipo de tutorial, você deve ter um mapa dentro do projeto que contém o nome "Demo". Este nível também deve conter documentação de alguma forma que ilustre como usar seu projeto. Veja o projeto Exemplos de Conteúdo da Epic para bons exemplos de como fazer isso. 1382 | 1383 | Se o seu projeto for uma mecânica de jogo ou outra forma de sistema em oposição a um pacote de arte, isso pode ser o mesmo que seu mapa "Overview". 1384 | 1385 | Por exemplo, `InteractionComponent_Overview_Demo`, `ExplosionKit_Demo`. 1386 | 1387 | **[⬆ Voltar ao topo](#table-of-contents)** 1388 | 1389 | 1390 | 1391 | 1392 | ## 7. Texturas 1393 | 1394 | Esta seção se concentrará em assets de textura e suas propriedades. 1395 | 1396 | ### Seções 1397 | 1398 | > 7.1 [Dimensões são poderes de 2](#textures-dimension) 1399 | 1400 | > 7.2 [A densidade da textura deve ser uniforme](#textures-dimension) 1401 | 1402 | > 7.3 [As texturas não devem ser maiores que 8192](#textures-max-size) 1403 | 1404 | > 7.4 [Grupos de textura corretos](#textures-textures-group) 1405 | 1406 | 1407 | 1408 | ### 7.1 Dimensões são poderes de 2 1409 | 1410 | Todas as texturas, exceto as texturas de IU, devem ter suas dimensões em múltiplos de potências de 2. As texturas não precisam ser quadradas. 1411 | 1412 | Por exemplo, `128x512`,` 1024x1024`, `2048x1024`,` 1024x2048`, `1x512`. 1413 | 1414 | 1415 | 1416 | ### 7.2 A densidade da textura deve ser uniforme 1417 | 1418 | Todas as texturas devem ter um tamanho apropriado para seu caso de uso padrão. A densidade de textura apropriada varia de projeto para projeto, mas todas as texturas dentro desse projeto devem ter uma densidade consistente. 1419 | 1420 | Por exemplo, se a densidade da textura de um projeto é de 8 pixels por 1 unidade, uma textura que deve ser aplicada a um cubo de 100x100 unidades deve ser 1024x1024, pois é a potência mais próxima de 2 que corresponde à densidade da textura do projeto. 1421 | 1422 | 1423 | 1424 | ### 7.3 As texturas não devem ser maiores que 8192 1425 | 1426 | Nenhuma textura deve ter uma dimensão que exceda 8192 em tamanho, a menos que você tenha um motivo muito explícito para fazer isso. Freqüentemente, usar uma textura tão grande é simplesmente um desperdício de recursos. 1427 | 1428 | 1429 | 1430 | ### 7.4 As texturas devem ser agrupadas corretamente 1431 | 1432 | Cada textura possui uma propriedade "Texture Group" usada para LOADing, e isso deve ser definido corretamente com base em seu uso. Por exemplo, todas as texturas da IU devem pertencer ao grupo de textura da IU. 1433 | 1434 | **[⬆ Voltar ao topo](#table-of-contents)** 1435 | 1436 | 1437 | ## Principais Contribuintes 1438 | 1439 | * [Michael Allar](http://allarsblog.com): [GitHub](https://github.com/Allar), [Twitter](https://twitter.com/michaelallar) 1440 | * [CosmoMyzrailGorynych](https://github.com/CosmoMyzrailGorynych) 1441 | * [billymcguffin](https://github.com/billymcguffin) 1442 | * [akenatsu](https://github.com/akenatsu) 1443 | 1444 | ## Licença 1445 | 1446 | Copyright (c) 2016 Gamemakin LLC 1447 | 1448 | Veja [LICENSE](/LICENSE) 1449 | 1450 | **[⬆ Voltar ao topo](#table-of-contents)** 1451 | 1452 | 1453 | ## Emendas 1454 | 1455 | Recomendamos que você crie um fork deste guia e altere as regras para se adequar ao Guia de Estilo de sua equipe. Abaixo, você pode listar algumas alterações ao Guia de Estilo. Isso permite que você atualize periodicamente seu guia de estilo sem ter que lidar com conflitos de mesclagem. 1456 | 1457 | # }; 1458 | -------------------------------------------------------------------------------- /docs/gettingstarted.md: -------------------------------------------------------------------------------- 1 | # Getting Started 2 | 3 | ## Requirements 4 | 5 | * You will need a launcher version of Unreal Engine 4 version 4.24 or later. 6 | * You must purchase (for free) the Linter plugin on the Unreal Engine Marketplace. 7 | 8 | @TODO: Add link here once I have it 9 | 10 | ## Installing From The Launcher 11 | 12 | 1. Close all your instances of Unreal Engine 4 13 | 2. Using the Epic Launcher find Linter in your Vault 14 | 3. Use the Install to Engine button to install Linter to your Engine 15 | 16 | ![](img/LinterLauncher.png) 17 | 18 | ## Enabling Linter 19 | 20 | 1. Open your project 21 | 2. Open the Plugins window by clicking Edit on the main toolbar and navigating to Plugins 22 | 3. Search for Linter 23 | 4. Enable the Linter plugin by ensuring the Enabled checkbox is checked 24 | 5. Restart the editor 25 | 26 | ## Using Linter 27 | 28 | Once installed there isn't much in the way of using Linter. Operating Linter is pretty straightforward: 29 | 30 | 1. Right-click on a content folder in your project 31 | 2. Click "Scan with Linter" 32 | 3. Select the ruleset you would like to use for linting 33 | 4. Wait for the results 34 | 35 | ![](img/ScanWithLinter.png) 36 | 37 | ## The Lint Report 38 | 39 | Once a project is scanned, you will be presented with a Lint Report that provides an overall summary of the state of your project. 40 | 41 | ![](img/LintReport.png) -------------------------------------------------------------------------------- /docs/howitworks.md: -------------------------------------------------------------------------------- 1 | # How Does Linting Work? 2 | 3 | Linter's bundled rulesets are included in the Linter Plugin content folder. Engine and Project plugin folders might be hidden in your engine. To show them, make sure the checkboxes next to Show Engine Content and Show Plugin Content are both checked in your Content Browser's View Options. 4 | 5 | ![](img/ShowPluginContent.png) 6 | 7 | ## Dissecting a Linter Rule Set 8 | 9 | ![](img/MarketplaceLinterFolder.png) 10 | 11 | Linters are defined by `LintRuleSets`, essentially a fancy [Data Asset](https://www.youtube.com/watch?v=gLWXZ3FXhO8). In the above example, we are looking at the `MarketplaceLintRuleSet` asset which defines all of the rules we want to use when scanning for marketplace guideline compliance. 12 | 13 | ![](img/MarketplaceLintRuleSet.png) 14 | 15 | In the above image you'll see that this `LintRuleSet` uses a `NamingConvention` Data Asset named `MarketplaceNamingConvention` In addition to a NamingConvention asset, `LintRuleSet` assets also contain something called a Class Lint Rules Map. This is a map of Unreal Engine 4 classes paired with a list of `LintRules`, which are assets that make up individual rules that we'll cover later. 16 | 17 | ![](img/LintRulesMap.png) 18 | 19 | When objects in an Unreal Engine 4 project are linted, they are scanned using the rules that match the "most specific" class defined in the Class Lint Rules Map. You can use any class in this map, with the base `UObject` being a special case. 20 | 21 | Unfortunately at this time the Unreal Engine 4 editor does not allow `UObject` as a valid value as a key in this Class Lint Rules Map, so if you want to define rules that you want to scan `UObjects` with, please use the `AnyObject_LinterDummyClass` class instead. 22 | 23 | With the above example ruleset, when the Linter comes across a `UBlueprint` asset it will scan that asset using the four lint rules defined above. This is because `UBlueprint` is a more specific class definition than `UObject`. Another asset type, such as a data asset, will instead use the `AnyObject_LinterDummyClass` rules when being scanned unless there is a more specific matching class defined in the ruleset than `UObject`. 24 | 25 | **NOTE:** Currently there isn't support for allowing cascading rule checks, i.e. allowing a `UBlueprint` being scanned against rules paired with `UBlueprint` *as well as* `UObject`. This support is planned to be added in a future release. See [todo](/todo). 26 | 27 | ## How Lint Rules Are Implemented 28 | 29 | While `LintRules` can be implemented in both Blueprint and C++, currently there aren't too many functions exposed to Blueprint that deal with asset metadata and lower level asset management checks and tasks. It is currently strongly recommended that you do your rule checking logic in C++ and then only expose configuration settings to a Blueprint class. 30 | 31 | All of Linter's bundled `LintRules` are Blueprint child classes that parent from a native C++ `LintRule`, with the goal that the Blueprint `LintRules` only expose configuration options. 32 | 33 | ### PassesRule_Internal_Implementation 34 | 35 | The core of implementing your own `LintRule` is to implement the `PassesRule_Internal_Implementation` function. This function can be implemented in either C++ or Blueprint as this is a `BlueprintNativeEvent`. 36 | 37 | This should be where the business logic of your `LintRule` operates. To report a rule violation, push a new `FLintRuleViolation` to the `OutRuleViolations` array and return false. You should always return false if **any** rule is violated and you should always return true if **no** rules were violated. A `FLintRuleViolation` is simply a struct that has a reference to the asset that is violating the rule, a reference to the rule that is being violated, and potentially any additional optional recommended text to display to the user reading the Lint Report. 38 | 39 | Implementing this function is all you need for your `LintRule` to be functional and ready for use. For the sake of example, here is how the Unreal Engine Marketplace Guideline rule for ensuring your textures are not too big is implemented: 40 | 41 | ```cpp 42 | bool ULintRule_Texture_Size_NotTooBig::PassesRule_Internal_Implementation(UObject* ObjectToLint, const ULintRuleSet* ParentRuleSet, TArray& OutRuleViolations) const 43 | { 44 | const UTexture2D* Texture = CastChecked(ObjectToLint); 45 | 46 | int32 TexSizeX = Texture->GetSizeX(); 47 | int32 TexSizeY = Texture->GetSizeY(); 48 | 49 | // Check to see if textures are too big 50 | if (TexSizeX > MaxTextureSizeX || TexSizeY > MaxTextureSizeY) 51 | { 52 | FText RecommendedAction = NSLOCTEXT("Linter", "LintRule_Texture_Size_NotTooBig_TooBig", "Please shrink your textures dimensions so that they fit within {0}x{1} pixels."); 53 | OutRuleViolations.Push(FLintRuleViolation(ObjectToLint, GetClass(), FText::FormatOrdered(RecommendedAction, MaxTextureSizeX, MaxTextureSizeY))); 54 | return false; 55 | } 56 | 57 | return true; 58 | } 59 | ``` 60 | 61 | In the above code, we simply check to see if the `ObjectToLint` is a texture with width or height exceeding a `MaxTextureSizeX/MaxTextureSizeY`, which is defined in our Blueprint child as `8192`. This allows us to easily scan for textures that are bigger than 8k. If we ever want to decrease or increase the size of our textures allowed under this rule, we can easily do so by editing the `MaxTextureSizeX/MaxTextureSizeY` in Blueprint without requiring any code changes or code compiling. 62 | 63 | It is recommended that you create a Blueprint child of your native classes to fill out the Rule's display info. This way the rule can also have verbiage updates without requiring code edits. 64 | 65 | ![](img/LintRulesInBP.png) 66 | 67 | ### PassesRule Is Most Likely Not What You Want 68 | 69 | `LintRules` also have a virtual function called `PassesRule`. This is not meant for containing the business logic of your `LintRule`. This is a public `BlueprintCallable` function that allows your `LintRule` to have a Blueprint implementation of `PassesRule_Internal_Implementation`. 70 | 71 | You should only implement this if you want to "early out" of the linting process. Linter's strategy is to try to implement error handling in `PassesRule` for things like possible null checks or invalid objects and then only performing the actual scan logic inside `PassesRule_Internal_Implementation`. You **do not** need to implement your own `PassesRule`. 72 | 73 | ### IsRuleSuppressed is optional 74 | 75 | `LintRules` can also be programmatically suppressed by implementing the `IsRuleSuppressed` function. This function is called automatically by the base `PassesRule` implementation. If you want to simply suppress a rule, do so here instead of `PassesRule`. 76 | 77 | ## How Lint Naming Conventions Are Implemented 78 | 79 | `NamingConvention` assets are simply a list of naming conventions as a data asset. `LintRules` will have access to the `NamingConvention` data asset that is defined in the lint rule's parent `LintRuleSet`. The `NamingConvention` data asset isn't responsible for any implementation logic. Instead `LintRules` are written to perform these naming convention checks using the given `NamingConvention` data asset as configuration. 80 | 81 | ## LintRuleCollections... collect rules 82 | 83 | Sometimes it is easier to treat a collection of rules as a single rule. In this case, you can create a `LintRuleCollection` class that simply defines a list of other `LintRules`. This is very useful when dealing with repetitive path and file name lint rules. 84 | 85 | ## Video Walkthrough of Creating A LintRuleSet 86 | 87 | @TODO: Get this edited, uploaded, submitted, embedded 88 | 89 | ## Automated Linting via Commandlets 90 | 91 | The Linter plugin adds a Commandlet that you can run against your project via commandline. It will return an error code of 1 if the linting process fails for any reason. It will return an error code of 2 if Linter reports any errors, or warnings as well if `-TreatWarningsAsErrors` is passed on the commandline. 92 | 93 | To invoke the commandlet, run your Editor binary (i.e. `D:\UE424\Engine\Binaries\Win64\UE4Editor-Cmd.exe`), followed by the path to your `.uproject` (i.e. `"C:\Users\Allar\Documents\Unreal Projects\Linterv2Test\Linterv2Test.uproject"`), followed by the arg `-run=Linter`. 94 | 95 | Full command for example, `D:\UE424\Engine\Binaries\Win64\UE4Editor-Cmd.exe "C:\Users\Allar\Documents\Unreal Projects\Linterv2Test\Linterv2Test.uproject" -run=Linter`. 96 | 97 | This will run Linter against the `/Game` path, a.k.a. your project's path, and return error code 0 if there are no errors. 98 | 99 | ### Specifying which Lint Rule Set to use 100 | 101 | All Lint Rule Sets now have a filed named `Commandlet Name` which represents a simple name to identify them via commandline. 102 | 103 | The Gamemakin LLC UE4 Style Guide's `Commandlet Name` is `ue4.style`, where the Unreal Engine Marketplace Guidelines uses the name `marketplace`. 104 | 105 | To specify this, use the `-RuleSet=` arg. For example, `-RuleSet=ue4.style` will use the Gamemakin lint rule set. `-RuleSet=marketplace` will use the UnrealEngine Marketplace Guidelines. If `-RuleSet=` is not provided, Linter will use the project's default Lint Rule Set. 106 | 107 | ### Additional Args 108 | 109 | #### Content Paths 110 | 111 | You can tell Linter to scan a list of folders to scan. They should generally be in the UE4 path form of `/Game/Content/...`. If a path includes spaces, wrap it in quotes. 112 | 113 | For example, if you only wanted to scan folders `Apple` and `Orange Stuff` inside your project's `Content` folder... 114 | 115 | `D:\UE424\Engine\Binaries\Win64\UE4Editor-Cmd.exe "C:\Users\Allar\Documents\Unreal Projects\Linterv2Test\Linterv2Test.uproject" /Game/Content/Apple "/Game/Content/Orange Stuff" -run=Linter`. 116 | 117 | This will scan both the `Apple` and `Orange Stuff` folders inside your project's `Content` folder. You can also pass in `Engine` and plugin folders. If no path is provided, the default will always be `/Game`. 118 | 119 | #### JSON Report 120 | 121 | To generate a `.json` report, you can add the switch `-json` to generate a `.json` report in your project's `Saved/LintReports/` folder. You can override the name of the report via `-json=ReportName.json`. If you specify a relative path it will be relative to the `Saved/LintReports/` folder. You can also provide an absolute path to write the `.json` report to. 122 | 123 | #### HTML Report 124 | 125 | To generate a `.html` report, you can add the switch `-html` to generate a `.html` report in your project's `Saved/LintReports/` folder. You can override the name of the report via `-html=ReportName.html`. If you specify a relative path it will be relative to the `Saved/LintReports/` folder. You can also provide an absolute path to write the `.html` report to. 126 | 127 | #### TreatWarningsAsErrors 128 | 129 | If you use the `-TreatWarningsAsErrors` switch, Linter will return an error code of 2 if the report contains any warnings. By default, Linter only returns an error code if it fails to lint or if the lint report contains errors. -------------------------------------------------------------------------------- /docs/img/LintReport.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/LintReport.png -------------------------------------------------------------------------------- /docs/img/LintRulesInBP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/LintRulesInBP.png -------------------------------------------------------------------------------- /docs/img/LintRulesMap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/LintRulesMap.png -------------------------------------------------------------------------------- /docs/img/LinterLauncher.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/LinterLauncher.png -------------------------------------------------------------------------------- /docs/img/MarketplaceLintRuleSet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/MarketplaceLintRuleSet.png -------------------------------------------------------------------------------- /docs/img/MarketplaceLinterFolder.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/MarketplaceLinterFolder.png -------------------------------------------------------------------------------- /docs/img/ScanWithLinter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/ScanWithLinter.png -------------------------------------------------------------------------------- /docs/img/ShowPluginContent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/docs/img/ShowPluginContent.png -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | # Welcome to Linter and Gamemakin LLC Style Guide Documentation 2 | 3 | This is the official documentation for Linter and the [Gamemakin LLC Style Guide](http://ue4.style). If you are looking for help or support, please try the [Gamemakin LLC Community Discord](http://discord.gamemak.in). 4 | 5 | ## About Linter 6 | 7 |
8 | 9 |
10 | 11 | Linter is an Unreal Engine 4 plugin available on the Unreal Engine Marketplace that can be used for automated scanning and reporting of a UE4 project's adherence to style guide standards. It can scan through all of your project's content using programmatic rulesets and tell you when you aren't following a rule. This is a fairly common type of tool usually seen in web development, but now we can do it with Unreal Engine! 12 | 13 | By default Linter is bundled with two rule sets: 14 | 15 | 1. The [Unreal Engine Marketplace Guidelines](https://www.unrealengine.com/marketplace-guidelines) 16 | 1. The [Gamemakin LLC Style Guide](http://ue4.style) 17 | 18 | ## About the Gamemakin LLC Style Guide 19 | 20 | While Linter is now capable of supporting multiple rule sets, Linter was originally developed with the Gamemakin LLC Style Guide in mind. This style guide is an opinionated set of guidelines written by [Michael Allar](http://www.twitter.com/michaelallar) for Unreal Engine 4 projects that continue to grow, change, and respond to newer and better organization patterns as well as community feedback. 21 | 22 | This style guide is not meant to be the definitive solution to all projects, but it is open-sourced in the hopes that those without style guides can use it as a starting point for their practices and try to come to a common consensus to many aspects of working with Unreal Engine 4. 23 | 24 | It can be found at the following URL: [http://ue4.style](http://ue4.style) 25 | 26 | ## About the Unreal Engine Marketplace Guidelines 27 | 28 | If you are creating content for the Unreal Engine Marketplace, your content must adhere to Epic's guidelines [which can be found on their site](https://www.unrealengine.com/marketplace-guidelines). 29 | 30 | Linter, Gamemakin LLC, and Michael Allar do not have any control or influence over these guidelines as well as whether your assets meet the required standards for the Unreal Engine Marketplace, but Linter is designed to help you conform to their rules by scanning your project against the rules they will be validated with. -------------------------------------------------------------------------------- /docs/style.md: -------------------------------------------------------------------------------- 1 | # Gamemakin LLC Style Guide 2 | 3 | For information about how Linter scans against the Gamemakin LLC Style Guide, please see the style guide itself at [http://ue4.style](http://ue4.style) as the style guide is marked up with its own Linter annotations. -------------------------------------------------------------------------------- /docs/todo.md: -------------------------------------------------------------------------------- 1 | # The Future of Linter and the Gamemakin LLC Style Guide 2 | 3 | This page documents active efforts with Linter and the Gamemakin LLC Style Guide that may be in progress or otherwise incomplete. 4 | 5 | ## Planned Future Features 6 | 7 | 1. Finish video tutorial on the creation of a new lint ruleset 8 | 1. Allowing rule scanning to support multiple class matches in a class lint rules map 9 | 10 | ## Future Considerations 11 | 12 | * Figure out a way to facilitate community lint rule sets -------------------------------------------------------------------------------- /docs/unrealguidelines.md: -------------------------------------------------------------------------------- 1 | # Unreal Engine Marketplace Guidelines 2 | 3 | This page covers how Linter implements rule sets based off of the [Unreal Engine Marketplace Guidelines](https://www.unrealengine.com/marketplace-guidelines). Not every guideline is currently supported but it is the goal of Linter to continually improve support for the Unreal Engine Marketplace Guidelines as well as other commonly used style guides. 4 | 5 | If you would like to contribute by adding support for additional guidelines, please join the discussion in the [Gamemakin LLC Community Discord](http://discord.gamemak.in). 6 | 7 | ## Disclaimer 8 | 9 | You are not guaranteed to have your product submission accepted by the Unreal Engine Marketplace simply because you might pass all these rules, however failing these rules will make your submission incredibly more likely to be rejected. 10 | 11 | ## 2.3.6 Particle Effects 12 | 13 | ### 2.3.6.b [Particle emitter names must be accurate and relevant and must not be "Particle Emitter" unless they're the only emitter in a given particle system](https://www.unrealengine.com/en-US/marketplace-guidelines#236b) 14 | 15 | Linter's interpretation of this is to simply check to see if a `UParticleSystem` asset has 2 or more emitters, and if it does, check to see if any of the emitters are named "Particle Emitter". If they are, then this rule is being violated. 16 | 17 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Particles_EmitterNames.MPLR_Particles_EmitterNames'`. 18 | 19 | ## 2.3.7 Textures 20 | 21 | ### 2.3.7.a [Both dimensions of each texture should have a size that is a power of 2 where applicable (e.g. 1024x512 or 1024x4096)](https://www.unrealengine.com/en-US/marketplace-guidelines#237a) 22 | 23 | Linter's interpretation is to do a simple "power of two" math test on both the width and the height of all textures. If a texture fails this power of two math test, it then is checked to see if it's `LODGROUP` is exempt from this rule. For the Unreal Engine Marketplace Guidelines, this rule set is configured to only allow textures of the `UI` `LODGROUP` to not have power of two sizes. 24 | 25 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Texture2D_PowerOfTwo.MPLR_Texture2D_PowerOfTwo'`. 26 | 27 | ### 2.3.7.b [Textures must have a maximum size in either dimension of 8192](https://www.unrealengine.com/en-US/marketplace-guidelines#237b) 28 | 29 | Linter's interpretation of this is to make sure a texture's width or height isn't bigger than 8192. That simple. 30 | 31 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Texture2D_Size_NotTooBig.MPLR_Texture2D_Size_NotTooBig'`. 32 | 33 | ## 2.4 Audio 34 | 35 | ### 2.4.c [Audio files must have a sample rate of 22050 Hz or 44100 Hz with no audio defects](https://www.unrealengine.com/en-US/marketplace-guidelines#24c) 36 | 37 | Linter's interpretation of this is pretty straight forward. `USoundWave` assets must have sample rates of either 22050 or 44100. 38 | 39 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_SoundWave_SampleRate.MPLR_SoundWave_SampleRate'`. 40 | 41 | ## 2.5 Blueprints 42 | 43 | ### 2.5.d [Blueprints must have no loose nodes unless they’re commented for example/tutorial purposes](https://www.unrealengine.com/en-US/marketplace-guidelines#25d) 44 | 45 | Linter's interpretation of this is that a `UBlueprint` that has any node on any of its graphs that has zero connections to any other node. 46 | 47 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Blueprint_LooseNodes.MPLR_Blueprint_LooseNodes'`. 48 | 49 | ### 2.5.e [Blueprints must generate no errors or consequential warnings](https://www.unrealengine.com/en-US/marketplace-guidelines#25e) 50 | 51 | Linter's interpretation of this is that a `UBlueprint` must not have a compile status of `BS_Error` or `BS_UpToDateWithWarnings`. 52 | 53 | That is, the compile button for this Blueprint should not have any error or warning icon on it. 54 | 55 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Blueprint_Compiles.MPLR_Blueprint_Compiles'`. 56 | 57 | ## 2.7 File Structure 58 | 59 | ### 2.7.1.a [Folder and files must be accurate and consistent in naming convention within the context of their project](https://www.unrealengine.com/en-US/marketplace-guidelines#271a) 60 | 61 | Linter's interpretation of this is that all assets should match a pattern defined in the rule set's `NamingConvention` asset. 62 | 63 | The Marketplace `NamingConvention` asset is `MarketplaceNamingConvention'/Linter/MarketplaceLinter/MarketplaceNamingConvention.MarketplaceNamingConvention'` and the rule that checks for this is `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_IsNamedCorrectly.MPLR_IsNamedCorrectly'`. 64 | 65 | ### 2.7.1.b [Folders and files must not be vaguely-named such as \"Assets\", \"NewFolder\", etc.](https://www.unrealengine.com/en-US/marketplace-guidelines#271b) 66 | 67 | Linter's interpretation of this is that all path elements must never be "Assets" or "NewFolder". 68 | 69 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Path_DisallowedPathNames.MPLR_Path_DisallowedPathNames'`. 70 | 71 | ### 2.7.1.c [Folder and file names must contain only English alphanumeric characters and underscores](https://www.unrealengine.com/en-US/marketplace-guidelines#271c) 72 | 73 | Linter's interpretation of this is that all path elements are tested against a Regular Expression `[^a-zA-Z0-9_]` which is only valid if the entire path element does not have any character except the letters "a through z", "A through Z", "0 through 9", and the '_' character. 74 | 75 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Path_AlphaNumeric.MPLR_Path_AlphaNumeric'`. 76 | 77 | ### 2.7.2.b [In order to reduce migration conflicts after importing project files from the Epic Games Launcher, all project-specific assets must be stored in one top level folder; there must be no other folders or files directly under the Content folder](https://www.unrealengine.com/en-US/marketplace-guidelines#272b) 78 | 79 | Linter's interpretation of this is that the parent folder of any asset should not be the path `/Content/`. 80 | 81 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Path_NoTopLevelAssets.MPLR_Path_NoTopLevelAssets'`. 82 | 83 | ### 2.7.2.d [Including the name of the top level folder under the Content folder, all asset file paths must be 140 characters or less](https://www.unrealengine.com/en-US/marketplace-guidelines#272d) 84 | 85 | Linter's interpretation of this is that the path of any asset returned by `UObject::GetPathName()`, with the redundant asset name chopped off, should not be longer than 140 characters. 86 | 87 | This is handled by `Blueprint'/Linter/MarketplaceLinter/LintRules/MPLR_Path_IsNotTooLong.MPLR_Path_IsNotTooLong'`. The path name that is used for this asset for example would be `/Linter/MarketplaceLinter/LintRules/MPLR_Path_IsNotTooLong'`. -------------------------------------------------------------------------------- /images/bp-graphs-align-wires-acceptable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/images/bp-graphs-align-wires-acceptable.png -------------------------------------------------------------------------------- /images/bp-graphs-align-wires-bad.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/images/bp-graphs-align-wires-bad.png -------------------------------------------------------------------------------- /images/bp-graphs-align-wires-good.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Allar/ue5-style-guide/198a8550947de91f19362dabf57fbd1f1cdf0904/images/bp-graphs-align-wires-good.png -------------------------------------------------------------------------------- /marketplace-compatibility.md: -------------------------------------------------------------------------------- 1 | # UE4 Marketplace TRC + Style Guide and Linter Compatibility 2 | 3 | Epic's Marketplace TRC can be found here: https://forums.unrealengine.com/showthread.php?151905-Marketplace-Technical-Review-Checklist 4 | 5 | This document shows its compatibility with the style guide on this repo, as well as the UE4 Marketplace Plugin Linter. 6 | 7 | ## Icon Guide: 8 | 9 | * :white_check_mark: - Compatible 10 | * :green_heart: - Linter Supported (Can currently be checked through automation) 11 | * :x: - Not Compatible 12 | * :o: - See note 13 | 14 | ## General 15 | 16 | | Line | Review Check Item | Compatibility Notes | 17 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 18 | | 4 | Submission is in Unreal Engine 4 | :white_check_mark::green_heart: If you can run Linter, you pass. | 19 | | 5 | Project contains correct files and folders | :white_check_mark: If you can run Linter, and distribute correctly, you pass. | 20 | | 6 | Submission contains enough primary assets | :o: You should generally always pass this. Could automate if this were more specific. | 21 | | 7 | Folder hierarchy is structured correctly | :x: This style guide actively fights against the folder structure desired. [See #2](http://ue4.style#2) | 22 | | 8 | First tier folders are named for asset type | :x: This style guide actively fights against the folder structure desired. [See #2](http://ue4.style#2) | 23 | | 9 | All files in perspective folders | :white_check_mark::green_heart: Although structure is incompatible, files are checked for structure. [See #2](http://ue4.style#2) | 24 | | 10 | Project is free of unused folders and assets | :white_check_mark::o: [See #2.2](http://ue4.style#2.2), [See #2.3](http://ue4.style#2.9), [See #2.9](http://ue4.style#2.9), and remove unused Epic starter / example content | 25 | | 11 | Naming conventions present, consistent, and acceptable | :white_check_mark::green_heart: [See #1](http://ue4.style#1) | 26 | | 12 | Assets names are in English and Alpha-Numeric | :white_check_mark::green_heart: [See #2.1.3](http://ue4.style#2.1.3) | 27 | | 13 | Assets names identify asset types | :white_check_mark::green_heart: [See #1](http://ue4.style#1) | 28 | | 14 | Assets names are consistent | :white_check_mark::green_heart: [See #1](http://ue4.style#1) | 29 | 30 | ## Maps 31 | 32 | | Line | Review Check Item | Compatibility Notes | 33 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 34 | | 16 | Pack contains Maps | :white_check_mark::green_heart: Linter will check for map issues if maps exist. | 35 | | 17 | Pack contains Overview Map | :white_check_mark: [See #6.4.1](http://ue4.style#6.4.1) | 36 | | 18 | Overview Map is set up appropriately and named correctly | :white_check_mark: [See #6.4.1](http://ue4.style#6.4.1) | 37 | | 19 | Lighting has been built on all maps | :white_check_mark: [See #6.2](http://ue4.style#6.2) | 38 | | 20 | All maps are free of errors and/or warnings | :white_check_mark::green_heart: [See #6.1](http://ue4.style#6.1) | 39 | | 21 | No Z fighting or overlapping polygons in maps | :white_check_mark: [See #6.3](http://ue4.style#6.3) | 40 | | 22 | Pack contains Demo Map | :white_check_mark: [See #6.4.2](http://ue4.style#6.4.2) | 41 | | 23 | Demo Map is set up appropriately and named correctly | :white_check_mark: [See #6.4.2](http://ue4.style#6.4.2) | 42 | | 24 | Displays functionality effectively | :white_check_mark: [See #6.4.2](http://ue4.style#6.4.2) | 43 | | 25 | In editor tutorial/documentation included | :white_check_mark: [See #6.4.2](http://ue4.style#6.4.2) | 44 | 45 | ## Quality 46 | 47 | | Line | Review Check Item | Compatibility Notes | 48 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 49 | | 27 | Assets are free of visibly obvious discrepancies | :o: Currently a subjective check. | 50 | | 28 | Assets function without detriment to performance | :o: Currently a subjective check. | 51 | | 29 | All assets are complete and function as intended | :o: Currently a subjective check. | 52 | | 30 | Assets are not easily reproduced | :o: Currently a subjective check. | 53 | | 31 | Pack contains overall good design and concepts | :o: Currently a subjective check. | 54 | 55 | ## Legal 56 | 57 | Gamemakin LLC and its product Linter makes no effort to check for legal compliance for your project on your behalf. We are not lawyers and do not have that capability and can not offer legal advice. That said, we vehemently recommend [not breaking the law](http://ue4.style#0.5). 58 | 59 | | Line | Review Check Item | Compatibility Notes | 60 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 61 | | 33 | Seller owns rights to distribute content | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 62 | | 34 | Does not contain copyrighted or trademarked content | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 63 | | 35 | Pack is free of stolen/pirated content | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 64 | | 36 | Epic/Unreal content is used for display/example only | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 65 | | 37 | Public Domain Content meets guideline requirements | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 66 | | 38 | Project is self-sustained | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 67 | | 39 | Additional requirements are available on the Marketplace | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 68 | | 40 | Pack does not contain assets that could be considered offensive | :white_check_mark: See section note. [See #0.5](http://ue4.style#0.5) | 69 | 70 | ## Textures 71 | 72 | | Line | Review Check Item | Compatibility Notes | 73 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 74 | | 42 | Pack contains Textures | :white_check_mark::green_heart: | 75 | | 43 | Textures are set to Power of 2 | :white_check_mark: [See #7.1](http://ue4.style#7.1) | 76 | | 44 | All textures are appropriate resolutions for their respective assets | :white_check_mark: [See #7.2](http://ue4.style#7.2) | 77 | | 45 | Maximum texture size is 8192 for general use and/or 2048 for mobile textures in either dimension | :white_check_mark: [See #7.3](http://ue4.style#7.3) | 78 | | 46 | All textures use the correct texture group based on purpose | :white_check_mark: [See #7.4](http://ue4.style#7.4) | 79 | 80 | ## Materials 81 | 82 | | Line | Review Check Item | Compatibility Notes | 83 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 84 | | 48 | Pack contains Materials | :white_check_mark::green_heart: | 85 | | 49 | All Materials are set up correctly and are optimized for intended purpose | :o: Currently a subjective check. | 86 | | 50 | Material instances used where appropriate | :o: Currently a subjective check. | 87 | | 51 | Mobile material assets use only BaseColor, Roughness, and Normal from textures | :o: Style guide has no mobile-specific distinctions. | 88 | | 52 | Specular is not specified unless used | :o: If "Yes" then "Yes", otherwise "No"? Too vague to understand. | 89 | 90 | ## Meshes 91 | 92 | | Line | Review Check Item | Compatibility Notes | 93 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 94 | | 54 | Pack contains Meshes | :white_check_mark::green_heart: | 95 | | 55 | LOD's are set up correctly | :white_check_mark: [See #4.2](http://ue4.style#4.2) | 96 | | 56 | Assets are modular | :o: 'Recommended Check'. It does not make sense to make this a hard rule, as hero assets are generally not modular. | 97 | | 57 | Modular pieces are adaptable for repurposing | :white_check_mark: This is the definition of modular. | 98 | | 58 | Assets snap cleanly on 10 cm grid | :white_check_mark: [See #4.3](http://ue4.style#4.3) | 99 | | 59 | Has collision | :white_check_mark: [See #4.4](http://ue4.style#4.4) | 100 | | 60 | Collision set up correctly | :white_check_mark: [See #4.4](http://ue4.style#4.4) | 101 | | 61 | PhysicsAssets correctly set up | :o::white_check_mark: Style Guide currently does not have rules for Skeletal Meshes. This will be enforced however. | 102 | | 62 | If less than 5 assets, all assets are rigged and animated | :o: Marketplace specific rule purely about quantity, guide does not apply. | 103 | | 63 | No overlapping Lightmap UVs | :white_check_mark::green_heart: [See #4.4](http://ue4.style#4.4) | 104 | | 64 | Assets scaled correctly | :white_check_mark: [See #4.5](http://ue4.style#4.5) | 105 | 106 | ## Blueprints 107 | 108 | | Line | Review Check Item | Compatibility Notes | 109 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 110 | | 66 | Pack contains Blueprints | :white_check_mark::green_heart: | 111 | | 67 | Blueprints use comments appropriately | :white_check_mark: [See #3.4.4](http://ue4.style#3.4.4) | 112 | | 68 | Blueprints are clean and easy to read | :white_check_mark: [See #3.4](http://ue4.style#3.4) and its subsections. | 113 | | 69 | Casts contain both a pass and fail condition | :o: Sometimes a graceful no-logic fail is acceptable. [See #3.4.5](http://ue4.style#3.4.5) | 114 | | 70 | Custom Blueprint nodes contain "Static" prefix | :x: If this refers to a node's name, this makes zero sense, and Epic doesn't follow this in any form. If this refers to the fact that a function might be static, this also makes no sense and this rule should be re-written. After several months I have not been able to get clarification from the marketplace team as to what is intended here. | 115 | | 71 | Custom Blueprint nodes from plugins categorized with plugin name as preface | :o: Style guide only applies this to static functions in a plugin. [See #3.3.5](http://ue4.style#3.3.5) | 116 | | 72 | Functions, variables, and events use names that reflect intended purposes | :white_check_mark: [See #3.3.1](http://ue4.style#3.3.1) | 117 | | 73 | No loose Blueprint nodes | :white_check_mark: [See #3.4.6](http://ue4.style#3.4.6) | 118 | | 74 | Blueprint is free of errors and/or warnings | :white_check_mark::green_heart: [See #3.1](http://ue4.style#3.1) | 119 | 120 | ## Audio 121 | 122 | | Line | Review Check Item | Compatibility Notes | 123 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 124 | | 76 | Pack contains Audio | :white_check_mark::green_heart: | 125 | | 77 | All wav files have sound cues attached | :o: This reads like a 1:1 relationship between SoundWaves and SoundCues, when its very common to have one SoundCue reference many SoundWaves. Not sure of Marketplace Team's intention. | 126 | | 78 | Audio is clean and not bitcrunched | :o: Currently a subjective check. | 127 | | 79 | Audio sample rate is appropriate (44100 Hz or 22050 Hz for Game Assets) | :o: Style guide currently does not have rules for audio format. | 128 | | 80 | Sound cues and wavs in separate "Cue" and "Wave" folders | :x: This style guide actively fights against the folder structure desired. [See #2](http://ue4.style#2) | 129 | 130 | ## Characters 131 | 132 | Gamemakin LLC's Style Guide does not have character specfics as characters are quite diverse. Epic forces characters to adhere to the Epic Skeleton for marketplace assets even when a character should have a different skeleton due to things like having facial animations, having articulation and movements not supported by Epic's skeleton, having wildly different proportions to the point where using even re-targeted Epic animations don't make sense, and other factors. 133 | 134 | When a humanoid does warrant being rigged to the Epic skeleton, we agree with every review item in this list. This checklist however is not fully compatible because we don't believe line item 83 should be enforced as strictly as it currently is. 135 | 136 | | Line | Review Check Item | Compatibility Notes | 137 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 138 | | 82 | Pack contains Characters | :white_check_mark::green_heart: | 139 | | 83 | Humanoid assets rigged to Epic skeleton | :o: See section note above. | 140 | | 84 | Bones are not renamed | :o::white_check_mark: If using Epic skeleton, agree completely. See Section note. | 141 | | 85 | Character is not weighted to any IK joints | :o::white_check_mark: If using Epic skeleton, agree completely. See Section note. | 142 | | 86 | Epic Skeleton IK Joints are in skeleton hierarchy | :o::white_check_mark: If using Epic skeleton, agree completely. See Section note. | 143 | | 87 | Joint orientations remain intact | :o::white_check_mark: If using Epic skeleton, agree completely. See Section note. | 144 | | 88 | Skeleton is not scaled | :o::white_check_mark: If using Epic skeleton, agree completely. See Section note. | 145 | 146 | ## Animation 147 | 148 | | Line | Review Check Item | Compatibility Notes | 149 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 150 | | 90 | Pack contains Animations | :white_check_mark::green_heart: | 151 | | 91 | All animations imported from individual .FBX files | :x: Does not make sense. What about animations baked from physical simulations within UE4? What about single frame poses extracted from animations used for reference and additive posing within UE4? What about .FBX's with multiple takes in standard mo-cap pipelines using Motion Builder? | 152 | | 92 | Animations are clean, consistent, and function as intended | :white_check_mark: All assets, regardless of type, should not be broken. | 153 | 154 | ## Weapons 155 | 156 | | Line | Review Check Item | Compatibility Notes | 157 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 158 | | 94 | Pack contains Weapons | :white_check_mark::green_heart: | 159 | | 95 | Weapons are scaled to epic skeleton and appear relatively scaled as intended when imported into a new project | :white_check_mark: [See #4.5](http://ue4.style#4.5) | 160 | | 96 | Weapons with moving parts are rigged and animated | :white_check_mark: Definition of a weapon with moving parts. Otherwise it wouldn't have moving parts. | 161 | 162 | ## Particle Effects 163 | 164 | | Line | Review Check Item | Compatibility Notes | 165 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 166 | | 98 | Pack contains Particle Effects | :white_check_mark::green_heart: | 167 | | 99 | Emitter names are accurate and relevant to their displayed effects |:white_check_mark::green_heart: [See #5.1](http://ue4.style#5.1) | 168 | | 100 | Particle systems meant to be viewed at multiple distances have correct LODs | :o: Currently a subjective check. | 169 | | 101 | Effects optimized for their intended use | :o: Currently a subjective check. | 170 | 171 | ## Plugins 172 | 173 | | Line | Review Check Item | Compatibility Notes | 174 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 175 | | 103 | Pack utilizes Plugins | :white_check_mark: | 176 | | 104 | Required plugins in project are available on UE Marketplace | :o: Marketplace specific rule, style guide does not apply. | 177 | | 105 | Unnecessary/Unused plugins are disabled | :o: Blueprint only projects can sometimes be forced to need C++ compiling when disabling unused built-in plugins. Until this is fixed, can not recommend fully disabling every unused plugin. | 178 | 179 | ## Notes From Reviewer 180 | | Line | Review Check Item | Compatibility Notes | 181 | | :---: | :------------------------------------------------------------------------- | :------------------------------------------------------------------------------ | 182 | | 107 | Changes have previously been requested | :o: Specific to Marketplace Review Process, style guide does not apply. | 183 | | 108 | Requested Changes Have Been Implemented | :o: Specific to Marketplace Review Process, style guide does not apply. | 184 | -------------------------------------------------------------------------------- /mkdocs.yml: -------------------------------------------------------------------------------- 1 | site_name: Linter and Style Guide Documentation 2 | nav: 3 | - Home: index.md 4 | - Getting Started: gettingstarted.md 5 | - How Does Linting Work?: howitworks.md 6 | - Unreal Engine Marketplace Guidelines: unrealguidelines.md 7 | - Gamemakin LLC Style Guide: style.md 8 | - TODO: todo.md 9 | theme: readthedocs -------------------------------------------------------------------------------- /readthedocs.yml: -------------------------------------------------------------------------------- 1 | # .readthedocs.yml 2 | 3 | # Required 4 | version: 2 5 | 6 | mkdocs: 7 | configuration: mkdocs.yml --------------------------------------------------------------------------------