Projects, Levels & Actors

Unreal's organisation is a strict nesting of four things. A project is the whole thing - a folder on disk holding every asset, every setting and every level for one piece of work. Open Unreal and you open a project; your house scheme is one project, a different client is another. Inside a project are levels (Unreal sometimes calls a level a map). A level is one 3D world you open and edit - a scene. You might keep the ground floor in one level and the site in another, or the whole small project in a single level. Crucially, the editor works on one level at a time - the world you see in the Viewport is the currently open level.

Inside a level are actors. An actor is anything placed in the world: a wall mesh, the sun (a Directional Light), a camera, a chair, a post-process volume, a Player Start. If it exists in the scene, it is an actor. And inside an actor are components - the parts that make it up. A wall actor has a Static Mesh component (its geometry) and probably a collision component; a lamp actor might have a mesh component and a Point Light component. Components are how one actor can be several things at once - a shape you see and a light that shines. So the full sentence to memorise is: a project holds levels, a level holds actors, an actor is built from components.

The World Outliner (top-right panel) is the level's table of contents: a live, named list of every actor in the open level, which you can search, sort and - importantly - organise into folders. This is where a scene stays sane or descends into a swamp of Cube, Cube2, StaticMeshActor7. The discipline is dull and completely worth it: name actors meaningfully and group them into folders - a Lighting folder for your sun, sky and interior lights; a Cameras folder; a GroundFloor folder; a Site folder. A well-kept Outliner lets you find, hide and select whole systems of the building at once.

The Outliner also shows attachment - actors parented to other actors. If you attach a set of chairs to a table actor, moving the table moves the chairs with it, and the Outliner shows them nested underneath. That is the scene-level cousin of the component hierarchy inside a single actor, and it is how you build assemblies that move as one. Two small habits pay for themselves all course long: toggle an actor's visibility (the eye icon) to declutter while you work, and use folders so that when a scene grows to hundreds of actors - as an imported building will in Module 2 - you are steering a labelled hierarchy, not scrolling a wall of anonymous entries. Treat the Outliner like the sheet index of a drawing set: the person who keeps it tidy moves fastest.

There is a second, quieter reason organisation matters here. Because actors can be instances that share a single underlying asset, a level made of a hundred identical balusters can reference one mesh a hundred times - and editing that one asset updates all hundred at once. A well-organised Outliner and Content Browser make that power usable: you can find the shared asset, understand what depends on it, and change it with confidence rather than hunting through anonymous duplicates. Sloppy naming does not just look unprofessional; it actively hides the relationships that make an Unreal scene efficient to edit. So the foldering habit is not cosmetic - it is how you keep a growing building comprehensible to yourself two months from now.

Every actor has a transform - three groups of numbers that place it in the world, visible in the Details panel and drivable with the W/E/R gizmo. Location is its X, Y, Z position; Rotation is its pitch, yaw and roll in degrees; Scale is its size multiplier, where 1.0 means real-world size. Two facts about Unreal transforms save architects real pain. First, Unreal's unit is the centimetre - a location of (200, 0, 0) is two metres along X - so if you bring geometry in at correct real-world scale, one Unreal unit equals one centimetre and a 2.1 m door reads as a 2.1 m door. Getting scale right on import (Module 2) is why a scene feels bodily correct in VR later.

Second, understand local vs world transforms and the value of locking scale to uniform. When you scale an actor, lock the ratio so a chair does not stretch into a funhouse version of itself; non-uniform scaling also complicates lighting and collision, so prefer to model or import at the right size and keep scale at 1.0 wherever you can. The transform is also where snapping earns its keep: with grid snap on, typing or dragging a Location moves the actor in tidy 10 cm steps, and angle snap rotates in clean 15-degree increments, so walls meet squarely instead of drifting to 89.3 degrees. Precision here is not fussiness - a real-time model that is true to scale and square is one you can measure, walk and trust, which is the entire point of taking a design into real-time.

Here is a trap that catches every newcomer, so learn it before it bites: saving in Unreal is not one button. The prominent Save on the toolbar saves the current level. But assets you have changed - a material you edited, a Blueprint you built - and the project's own settings are saved separately. The safe habit is File -> Save All (there is a shortcut), which writes the level and every modified asset at once. Get in the reflex of Save All before you close, before you Play, and before anything risky. Losing an hour because you saved the level but not the material you spent that hour making is a rite of passage worth skipping.

Because a project is a folder on disk, it is also easy to back up and to version - just copy the folder, or put it under version control, and you have a safe restore point. Levels live as files inside that folder (in the project's Content), which is why you can have several and open them one at a time. A couple of professional habits close the loop: keep the Content Browser organised into clear folders that mirror your Outliner thinking (Meshes, Materials, Maps/Levels, Blueprints), and save incrementally-named copies of a level at milestones so you can roll back. None of this is glamorous, but a real-time project is a living, heavy thing that you will reopen for months - the discipline of clean saving and foldering is what makes it a pleasure to return to rather than a scavenger hunt.

One more habit belongs here because it prevents the worst kind of loss. A project folder contains generated, rebuildable files - shader caches, derived data - that you never need to back up, but it also contains your irreplaceable Content (your levels, meshes, materials and Blueprints) and your Config and project settings, which you absolutely do. When you copy or version a project, make sure those are what you preserve; when disk space is tight, the caches are safe to let the engine regenerate. And if you work with anyone else, put the project under proper version control from the start rather than emailing zipped folders - a real-time project grows large fast, and a clean history is worth setting up on day one, not after the first painful overwrite.