🧭 Lesson 1.2: The Unreal Editor for Programmers

The Editor at a Glance

When you open a project, the Unreal Editor presents a default layout. As a programmer, five regions matter to you far more than the rest:

You do not have to master lighting, materials, or modeling to be productive. Your job is to write classes; the editor's job is to let you (and designers) instantiate, configure, and observe them.

Panels a Programmer Lives In

How Code Reaches the Editor

This is the concept that trips up newcomers. When you write a C++ class and compile, the editor doesn't magically "see" your source files. Instead, a build step compiles your module into a binary (a DLL on Windows), and the editor loads that binary. Your classes then appear through the reflection system — the same bridge from Lesson 1.1.

Two practical consequences follow immediately:

• A UCLASS you write shows up under Content Browser → C++ Classes → [YourProject]. You can right-click it to create a Blueprint child.
• A property you mark with UPROPERTY(EditAnywhere) automatically appears in the Details panel — no UI code needed. The editor builds the widget from the type.

💡 Why this matters: "Expose it and the editor draws it" is one of Unreal's superpowers. Much of Module 2 and Module 6 is about controlling exactly how your C++ surfaces here.

The Project on Disk

The editor is a view onto a folder structure. Knowing that structure keeps you oriented, especially when things go wrong. A C++ project looks like this:

MyProject/
├── MyProject.uproject        # Project descriptor (modules, plugins, engine version)
├── Config/                   # .ini settings (DefaultEngine.ini, DefaultGame.ini...)
├── Content/                  # All assets you see in the Content Browser (.uasset/.umap)
├── Source/                   # Your C++ lives here
│   ├── MyProject/            # A game module
│   │   ├── MyProject.Build.cs        # Module build rules & dependencies
│   │   ├── MyProject.h / .cpp        # Module implementation
│   │   └── (your .h and .cpp files)
│   ├── MyProject.Target.cs           # Build target: the game
│   └── MyProjectEditor.Target.cs     # Build target: the editor
├── Plugins/                  # Optional plugins (often with their own Source/)
├── Binaries/                 # Compiled output (generated — not committed)
├── Intermediate/             # Build scratch (generated — safe to delete)
└── Saved/                    # Logs, autosaves, config caches (generated)

Play-In-Editor & the Output Log

The Play button (or Alt+P) launches Play-In-Editor — your game running inside the editor process. It's the tightest test loop you have: no packaging, no separate launch. For C++ work, PIE plus the Output Log is your debugger's front porch.

Here's the smallest possible taste of code you'll write to see something in that log — don't worry about the syntax yet, we build up to it across the module:

// Somewhere in an actor's BeginPlay(), which runs when play starts:
void AMyActor::BeginPlay()
{
    Super::BeginPlay();

    // This line prints to the Output Log — your first "Hello, Unreal".
    UE_LOG(LogTemp, Warning, TEXT("Hello from C++! Actor: %s"), *GetName());
}

When you press Play, Hello from C++! appears in the Output Log, tagged as a warning (which makes it easy to spot in yellow). We cover UE_LOG properly in Lesson 2.6, but you'll be leaning on it from your very first class.

Hands-on Exercise & Quiz

Summary

📚 Additional Resources

• Unreal Editor Interface (Epic)
• Unreal Engine Directory Structure (Epic)

🚀 What's Next?

You can find your way around. Now let's make the machine ready to compile: installing and configuring the C++ toolchain and IDE so your first build actually succeeds.