Gamemakin UE4 Style Guide() {

A mostly reasonable approach to Unreal Engine 4

Heavily inspired by the Airbnb Javascript Style Guide.

Repo Notice

This repo is now located at https://github.com/Allar/ue5-style-guide. The default branch of this repository has been renamed main.

This is currently for UE4. For UE5/v2, see the v2 branch

Linter and Style Guide Documentation

More technical documentation regarding Linter and the Style Guide can be found at our ReadTheDocs page.

Discuss This Style Guide

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.

Linking To This Document

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 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.

Forks And Translations

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.

• Korean Translation by ymkim50
• Russian Translation by CosmoMyzrailGorynych
• Japanese Translation by akenatsu
• Chinese Translation by Beijing Skylens Tech.
• Brazilian Portuguese Translation by danlvr.
• French Translation by Arnaud58

Table of contents

• Important Terminology
  • Levels/Maps
  • Identifiers
  • Cases
  • Variables / Properties
    • Property
    • Variable
• 0. Principles
  • 0.1 If your UE4 project already has a style guide, you should follow it
  • 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.3 Friends do not let friends have bad style
  • 0.4 A team without a style guide is no team of mine
  • 0.5 Don't Break The Law
• 00. Globally Enforced Opinions
  • 00.1 Forbidden Characters
    • Identifiers
• 1. Asset Naming Conventions
  • 1.1 Base Asset Name - Prefix_BaseAssetName_Variant_Suffix
    • 1.1 Examples
  • 1.2 Asset Name Modifiers
    • 1.2.1 Most Common
    • 1.2.2 Animations
  • 1.2.3 Artificial Intelligence
  • 1.2.4 Blueprints

Important Terminology

Levels/Maps

The word 'map' generally refers to what the average person calls a 'level' and may be used interchangeably. See this term's history here.

Identifiers

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...

Cases

There are a few different ways you can CaseWordsWhenNaming. Here are some common casing types:

PascalCase

Capitalize every word and remove all spaces, e.g. DesertEagle, StyleGuide, ASeriesOfWords.

camelCase

The first letter is always lowercase but every following word starts with uppercase, e.g. desertEagle, styleGuide, aSeriesOfWords.

Snake_case

Words can arbitrarily start upper or lowercase but words are separated by an underscore, e.g. desert_Eagle, Style_Guide, a_Series_of_Words.

Variables / Properties

The words 'variable' and 'property' in most contexts are interchangable. If they are both used together in the same context however:

Property

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.

When in the context of a class, it is often used to imply accessing previously defined data.

Variable

Usually refers to a variable defined as a function argument or a local variable inside a function.

When in the context of a class, it is often used to convey discussion about its definition and what it will hold.

0. Principles

These principles have been adapted from idomatic.js style guide.

0.1 If your UE4 project already has a style guide, you should follow it

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.

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.

"Arguments over style are pointless. There should be a style guide, and you should follow it."

Rebecca Murphey

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

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.

It also allows