Getting Started with Unreal Engine

When creating a new Unreal project, you have the option of a Blueprint-only project or a C++ + Blueprint project. Always start with C++ + Blueprint, even if you plan to write mostly Blueprints.

The two layers have clearly defined roles:

Think of C++ as writing the rules of a board game, and Blueprints as deciding how a particular player chooses to play within those rules.

A C++ Unreal project has a well-defined folder layout. Understanding what each part does prevents you from treating the project as a black box.

MyProject/
├── MyProject.uproject      ← Critical config file
├── Source/                 ← All C++ code lives here
│   └── MyProject/
│       ├── MyProject.Build.cs
│       ├── MyProject.h / .cpp
│       └── ... your classes ...
├── Content/                ← All assets (meshes, BPs, textures)
├── Config/                 ← Engine and project .ini settings
├── Binaries/               ← Compiled output (do not commit)
├── Intermediate/           ← Build artifacts (do not commit)
└── Saved/                  ← Logs, backups (do not commit)

The .uproject File

The .uproject file is a JSON config that tells Unreal how to load and compile your project — which engine version to use, which plugins are enabled, and which modules exist. Always keep it under version control. Losing or corrupting it can make your project unloadable.

The Source Folder

Unreal does not treat Source/ as "just code." It is tightly integrated into the engine's reflection and build pipeline. The Unreal Build Tool (UBT) and the Unreal Header Tool (UHT) process your headers before the compiler ever sees them — generating the glue code that makes UCLASS, UPROPERTY, and UFUNCTION macros work.

What to Commit to Version Control

A common mistake is organizing code by class type — putting all actors in one folder, all components in another. Unreal projects scale better when organized by gameplay domain (responsibility), not by technical type.

This structure makes it obvious where new logic belongs. It also naturally prevents "god classes" — bloated classes that accumulate unrelated responsibilities because everything lived in the same flat folder and it was easier to just add another function.

The guiding rule for everything in your project: C++ defines behavior and constraints. Content defines composition and tuning. A weapon's damage falloff curve belongs in a data asset, not hardcoded in C++. A character's jump height belongs in a Blueprint property exposed from C++, not buried in a constructor.

The Unreal Editor is not a static authoring tool. It is a live, running instance of the engine. Even when you are not in Play-In-Editor (PIE) mode, the editor is continuously running:

• Rendering — the viewport is rendering every frame
• Garbage collection — UObject GC runs on a regular tick
• Asset loading — streaming and async loading are active
• Input handling — some editor shortcuts hook into the input system
• Simulation systems — physics, particles, and Niagara can run in editor

This has practical implications:

PIE vs. Standalone

Play-In-Editor spawns a game world inside the editor process — fast to iterate but shares memory with the editor. Standalone launches a separate process and is closer to shipping behavior. Always test in Standalone before calling something "done."

Hot Reload vs. Live Coding

Unreal supports recompiling C++ without closing the editor: