After the last two posts on soft references and async loading I got a few messages: "Cool, but I just opened the editor for the first time — where do I even start?" Fair. Let's back up.

This post is the one I wish I'd read before my first UE project. It's not about gameplay or visuals — it's the thirty minutes of boring setup that determine whether you'll be happy with this project in six months or whether you'll be quietly rewriting it.

Pick a project template — but don't trust it

When you create a new project, Unreal hands you a template: Third Person, First Person, Top Down, Blank. Pick the one closest to your game. Default to Third Person if you're truly unsure — it has the most "real" stuff already wired (input, camera, character movement).

Two important toggles in the New Project window:

  • Starter Content: OFF. You'll never use the cube-platform demo assets, and they bloat your project by ~200MB plus add references you'll have to clean up later.
  • Raytracing: OFF unless you have a clear reason. It's heavy and most of its features (Lumen, Nanite) are already on by default in UE5.

Pick Blueprint as the project type even if you plan to write C++ eventually. You can add C++ to a Blueprint project the moment you actually need it — and you might not need it for months. Starting Blueprint-only keeps your iteration loop short.

The folder structure that actually scales

Don't be smart here. Use the convention everyone else uses:

CB0

Two rules:

  • Categorise by purpose, not by asset type. Content/Materials/Player/M_PlayerSkin is wrong. Content/Characters/Player/M_PlayerSkin is right. When you delete the player, everything related deletes with it.
  • Use a _Developers/<yourname>/ folder for scratch work. Anything there is implicitly "WIP, not yet for the project". Solo devs benefit too — it's where you put the test maps and one-off Blueprints you haven't decided to keep.

Naming conventions

Unreal has a community-standard naming convention. Use it:

  • BP_ Blueprint class (e.g. BP_PlayerCharacter)
  • M_ Material
  • MI_ Material Instance
  • T_ Texture
  • S_ Skeletal mesh, or SM_ Static Mesh
  • A_ Sound (audio)
  • Anim_ Animation Blueprint or sequence
  • WBP_ Widget Blueprint (UMG)
  • DA_ Data Asset
  • DT_ Data Table
  • E_ Enum
  • L_ Level / map
  • NS_ Niagara System

It looks pedantic for two days, then it saves your life every day after. The Content Browser's search bar becomes useful when you can type BP_ and see only Blueprints.

Set these project settings on day one

Open Edit → Project Settings and change these now, not later:

  • Engine → General Settings → Use Fixed Frame Rate: leave off in editor, but consider setting Max FPS to 120 in the editor preferences so the editor doesn't burn your GPU.
  • Engine → Rendering → Lumen Global Illumination: leave on if you're on UE5, but switch Software Lumen → Hardware Lumen only if you have an RTX-class GPU.
  • Maps & Modes → Default Maps: point both Editor Startup Map and Game Default Map at your level, not the engine sample.
  • Project → Description: fill in Company Name, Project Name, Copyright Notice. These end up baked into the executable later — don't ship "MyAwesomeGame © 2026 Epic Games".
  • Project → Packaging → For Distribution: OFF for now, but remember the toggle exists.

Version control — Git LFS, even if you're solo

Yes, even for a solo project. Future-you will thank present-you. The setup:

  1. Initialise a Git repo at the project root (same folder as the .uproject).
  2. Install Git LFS.
  3. Add a .gitattributes file that tracks binary files via LFS:

CB1

  1. Add a .gitignore that excludes the regeneratable folders:

CB2

  1. Commit early, commit often. Commit before any large refactor — git reset --hard can save you hours.

GitHub gives you 1GB of LFS storage free, then $5/mo for 50GB. Worth it.

What not to do — Day-One mistakes

  • Don't put everything in BP_PlayerCharacter. It's tempting because it has Tick, input, and a viewport. It's also the path to a 5000-node monster. Inventory? Separate component. Save system? Separate manager. Quests? Separate subsystem. The PlayerCharacter should orchestrate, not contain.
  • Don't rename folders inside the editor by closing it first. Use the Content Browser → right-click → Rename. Unreal updates references for you. Renaming via Windows Explorer breaks every reference silently.
  • Don't mix Marketplace assets into your normal folder tree. Keep them under Content/Marketplace/<PackName>/. When you update them, you don't want them tangled with your own assets.
  • Don't disable "Use Source Control" in editor settings. Even if you're not using Perforce, it's the toggle that makes the Content Browser show you which assets you've modified.

Common pitfalls

  • Forgetting to set the default map. You'll start packaging weeks later and the shipped game opens TemplateMap.umap instead of your title screen. Set both default maps now.
  • Working on Desktop instead of in a dedicated dev folder. Long path names on Windows + Unreal's deep folder nesting = path-length errors. Put your project under C:\Dev\<ProjectName>\ or similar.
  • Using spaces in the project name. Most things work, but some plugin packaging steps quietly break on spaces. MyGame is fine. My Awesome Game will bite you in month four.
  • Not enabling Symbol Server in Visual Studio if you're doing C++. Debugging engine crashes without symbols is misery. Project Settings → Programming → enable both Symbol Servers.

The 30-second recap

  • Template Third Person, Starter Content off.
  • Folders by purpose, not by asset type.
  • Naming convention everyone uses — BP_, M_, T_, WBP_, DA_, etc.
  • Project Settings: default maps, project description, packaging settings — set them on day one.
  • Git + LFS + .gitignore, even solo.
  • Player Character orchestrates; it does not contain.

This is the foundation. Anything you build on top of it benefits from these decisions. Anything you build without them you'll be refactoring eventually.

Next week: 10 Blueprint errors every beginner hits — and how to fix them. Once your project is set up, the first thing you'll do is wire up a few nodes. The second thing you'll do is get cryptic error messages. Decoded next Sunday.

— Marco