7 years, 11 months ago 0
Posted in: Projects, Samples

This post assumes you’ve read Design Concepts and Design Structure.

For offline reference, be sure to grab the document below.

FILE: Prefabs.doc


If you’ve ever had to deal with tons and tons of objects across multiple levels, you’ll inevitably want to group similar or complete carbon copies of items together for quicker upkeep. If you’ve added a desk lamp to twenty different office rooms in five different levels, wouldn’t it be nice to change the brightness of that light once instead of 100 times?

That’s the power of prefabs.

So, what exactly is a prefab?  Nothing more than a collection of geometry or game objects used inside of a level to reduce content creation.

  • A Prefab is a Level.  The only thing that makes a prefab different than a level is it exists inside a level.  A large city level can have several small prefab neighborhoods and those in turn can have repeatable prefab houses inside of each.

By keeping it simple and not special case, prefabs become an infrastructure that supports endless possibilities.  Any feature that exists for a level should exist for a prefab:

  • A collection of models (a bench, a bus stop sign, a garbage can).
  • A building with AI navigation and interaction nodes.
  • An enemy with a unique change (BadGuy_Type_4 with dual pistols).
  • A complex script sequence (depending on game script file handling).
  • A skybox with all associated FX and animation.
  • A Security Door (a door model & logic, security palm switch & logic, emergency lighting & logic, surrounded by cover nodes & path volumes).


  1. Repeat occurrences only have to be created once.  When the original prefab is modified, all instances of that prefab are updated.
  2. Multiple people can work on the same level by sectioning portions of the level into prefabs.  Each user works on their individual prefab, testing their work from the main level.

Game Usage

So, any selection can be saved as a prefab.  They can also be exploded (or ‘unzipped’) into the current level, spilling their parts into the level, no longer connected to its source.  At runtime, all prefabs are exploded, however.  All parts get their name prefixed to the prefab’s unique name.  All logic now points to individual occurrences, removing any event confusion.

The Concept

Every level is made with a number of items.  Take a look at the following diagram as an example:

Now let’s see how prefabs let several people work on the level:

  • The Art Team works on the Terrain A location:
  • Artist 1 models Building D with indoor lighting to be used in 2 locations
  • Artist 2 models Building C to be used in 4 locations.
  • Artist 3 models Building B to be used in 3 locations.
  • Artist 4 models Building A with indoor lighting to be used in 4 locations.
  • Artist 5 is lighting the whole level.  Some lighting features on-off logic with Gameplay.
  • The Audio department is working on ambient Sound for the level, mixed with Gameplay.
  • The Design Team is providing gameplay to the Ground B location:
  • Designer 3 is creating a generic prefab for assigning AI and stats for a Train Event.
  • Designer 2 is creating City Tower logic to be used in 4 separate places in Ground B.
  • And lastly, Designer 1 is providing gameplay for the overall level in the Main Level.

When a person is finished, they check in their prefab to Perforce.  When the main level is opened again, any existing prefab is updated with the latest changes.  When new content ready, the user can pick them from the Resource Browser to add to the level.

Example Level

Let’s take a level and section areas into prefabs, allowing groups of people to work on each section:

  •  A Designer takes a city block and creates a series of prefabs from it:
  • …Each building is named appropriately and saved as a prefab.
  • …A city block of prefabs is saved as one Action Zone (optional).
  • …The main level is now a framework of roads, game logic, prefabs and Action Zones.

Fig 4: Default Level

Fig 5: Level cut into Action Zones
  • Artists individually open each prefab building to edit it:
  • …They replace the stand-in model with a final version
  • …They can even add new objects like: doors, windows, lamps, lights, etc.
  • …They can open the neighborhood Action Zone to understand relations between each building prefab.
  • When a Designer re-opens the level, all prefabs are updated with changes the Artists have made.

Fig 6: Artist 2 works on Apartment in Action Zone

Fig 7: Artist 3 works on individual Motel prefab

Slicing Up Levels

How do you set up levels to use Action Zones?  How do you work in them?  How should logic be arranged in them?  Before we talk about Action Zones, we need to understand how the level played in the game (the Main or Master level) is organized.  Each level consists of four basic components:

Applying this concept to Action Zones, we can create a framework providing maximum flexibility for adding (or removing) parts of the main level without impacting the main level itself.  Each component can become a prefab for each Action Zone.

Some prefabs don’t have to be exclusive to an Action Zone; they can span several Action Zones.  This allows one person to check out a prefab to have access to the whole level.  The disadvantage is when Action Zones are move around in the main level requiring contents to be moved manually to their new position.


By their nature, prefabs placed in levels are instances of the original prefab.  If changes are made to the prefab, those changes propagate to all copies in every level.  This can be helpful for example, if you want to change a texture or a light across a hundred copies.  However, you might only want to make one small change.  You need a way to remember those individual changes, instead of creating a new prefab for each size, exponentially increasing the size of the game library.

This can be solved by tagging any differences and re-applying those differences after changes to the original is made.  Technically speaking, values unique to any type of object are stored in the parent prefab or level file to override its original values.  When a change to the original is made, all copies reflect that change unless the value has been overridden on the instance.

An “Allow Deltas” action (on the Property window) provides a way to maintain these overrides.  With a prefab selected and “Allow Deltas” on (set to true), unique values will be accepted and maintained.  If “Allow Deltas” is turned off, all values are reset to their default.

Fig 11: Currently, editing one prefab edits all of them.

Fig 12: By allowing Deltas, unique edits remain while any unchanged values inherit changes.

A viewport filter called “Highlight Deltas” can display objects that have deltas on them in a blue tint.  To prevent the need to open prefabs, another option is enabling Child-picking.  This ignores prefab containers and directly picks any object in view, no matter how deep they are nested.  Selected objects are normally outlined in red.  Once you select inside a prefab those objects are outlined cyan, letting you know any changes will be considered a Delta.  Use the Outliner in conjunction with these options to understand the hierarchy and what prefab your current selection is stored in.

Editing Prefabs

Two methods of prefab editing should exist:

  1. Edit the prefab in a new scene.
  2. Edit the prefab in the current level.

Fig 13: Editing prefab “A” in a new scene isolates the prefab from the original scene.

Fig 14: Editing prefab “A” within the level provides instant feedback for how it affects the larger scene.  (The fences will need to be modified.)

By editing the prefab within the current level, it removes switching back and forth between scenes to remember your changes.

“The Marker”

When you create a prefab from a selection in the level, the prefab’s origin is based on the level’s origin.  The origin of a prefab becomes its rotation point when placed in a larger level.  So, if the selection is far away from (0,0,0), the contents within the prefab become internally far away.  You might want the ability to pick the prefab’s origin when creating it.

We can accomplish this with The Marker.  It’s a moveable infinite XYZ axis (or “3D crosshairs”).  Before making a prefab from a selection, enable and place the Marker to mark the prefab’s origin (pivot) point.

Menu Options

File Menu Context Menu
Open (Close) Prefabs…
Reload    Open (Close)
Reload All    —
New…    New…
Make Unique    Make Unique
Explode (Children)    Explode (Children)
Explode    Explode

Creation Methods

There are two ways prefabs are created:

  1. A prefab is created in isolation and then added to a level (like any other asset).
  2. A prefab is created from a selection within a level and then saved.

Either way, a prefab is ultimately used in a larger level.  Where you create it — in an empty level or a populated level — is up to you.

Prefabs should feature testing like a level, allowing a person to play it in-game.  They can have global settings, like Skybox properties and even Player Starts.  Any prefab added into a larger level will automatically have their individual global settings, skybox, and Player Start excluded.

Saving Changes

It’s important to understand how changes to prefabs are saved!  Most of it depends on whether or not you have it checked out from Perforce.  If it’s part of a project but not checked out, it’s a read-only file, which never allows changes to be saved.

Perforce Status Delta? Can Edit?
Checked In



Checked Out



Checked In



Checked Out



Deltas are stored in the parent level (or parent prefab).  If you have that parent level checked out, then you don’t need the prefab checked out to save Deltas.

The ability to edit prefabs within a larger level requires a new Save dialog.  Without this improvement, it’s impossible to remember what’s been modified after extensive work.  This feature also provides a way to pick what to save.

 FIGURE 15: Save Dialog example.

The left column is Save All options.  Any entry checked will get saved when the Save All button is hit.  Check-marked options are remembered during the current session, providing a way to quickly save groups of files.  The Save All button also appears on the main toolbar.

The right column is the individual files.  You can save a file independent of the rest by hitting the single Save button next to the filename.  A yellow exclamation and blue disk button means the file has been modified since it was last saved.  Next to the path name is the file type to choose between level and prefab file extensions.  The last button pops an explorer dialog for picking a new location.

File Extensions

Prefabs are quickly becoming a way to group different game components together.  As this continues, the ability to differentiate what a prefab’s usage or contents will become lost.  Lighting, models, and buildings are immediate meta-types with more to come, such as audio or game logic.  To manage this growth, create file extensions for each of prefab type.

Prefab Type File Ext.
(default) Prefab (Interiors, Buildings, Action Zones, logic)


BSP Prefab (brushes, patches)


Light-housing Prefab (lights, models, logic)


Model Prefab (ASE, BSP, cover nodes)


Gameplay Prefab (Spawners, Monsters, InfoNulls, etc.)



Today’s games involve thousands, if not millions, of objects. Managing all that content, making quick changes, and sharing team efforts, becomes a massive burden without a prefab system in place. If you want to spend more time discovering what’s exciting about your game and less time playing 52,000 card pickup, then take the time to invest in a proper prefab feature.


Leave a Reply