Design Structure

11 years, 10 months ago 1
Posted in: Projects, Samples

Following Part 1: Design Concepts, this next post digs deeper and starts to merge those concepts with technology.


What makes gameplay fun and successful? Distinctive encounters that feature variety within the player’s toolkit and clear escalation in challenges and rewards. To find this pattern for success, let’s break apart what an encounter is and apply them to your project.

Game Pieces

A lot of pieces are needed to bring a game world to life. To help understand the complexity, take a look at the chart below.

Fig. 1: How a game is brought to life.

At the lowest level we have a raw game world waiting for something to happen in it. Now spray over a layer of “Reference Points” and we now have spots to help game logic understand the world. The game world is now aware, but not alive.

The next layer is “Hard Scripting”. This is where most games stop. Controllers and Data Nodes can be used to bring the world to life, offering dynamic interaction within the world, but they still need user-scripting to connect events. The last layer let’s us dynamically create events. Our game world is now completely alive and able to “think” for itself.

The Layout

It’s important to note the following metrics are based around typical action (FPS shooter) games. If your technology allows for more and the quality of gameplay doesn’t decrease with quantity, experiment with larger sizes.

During the initial layout, take into consideration future performance. Working back from those hard numbers, we can figure out the physical size each Action Zone can be within a level.

Define the area with up to ten “plates” (1024×1024). The following example showcases a variety of layouts Action Zones can have. Example A could be a mix of Track and Capture encounters. Example B could be a whole Action Zone devoted to exploration. Example C could be a street-to-street Chase encounter. The “plates” aren’t meant to be rigid rule set – only a tool used to stay within a general area of space.


Having these quick layouts can be used to also test draw distances. As a general rule of thumb, don’t string more than 2-3 “plates” together (~2500 units). Special vistas or establishing shots can ignore this limitation. Objects can exist outside of the play area, but should be non-interactive and built for high-performance.

To help manage memory and streaming elements (as well as providing a good story and action!), traversing from one Action Zone to another provides a great way to reset the pacing. These Transition Zones should be simple, non-descript routes and have no major impact on the overall budget.

Let’s take the previous examples, label the Transition Zones and potential Combat and Safe areas.


With these concepts in mind, let’s apply them to an example area…

Level Example

In the following example, Action Zones will incorporate all elements needed to bring a level to life. We’ll describe the pieces then discuss how three different scenarios can take place in it.


Fig. 4: A top down view of three Action Zones.

From the south, a street passes through Action Zone B, rising up to bridge over the area and exits to other Action Zones. An exposed Power Station sits in the northwest corner. Two buildings line the south side. A small, nondescript shack sits underneath the northern overpass. Below ground is a tunnel providing alternative routes between the four major areas.


Fig. 5: Action Zone B (looking east)


Fig. 6: Action Zone B (looking west)


Fig. 7: Top down view of the tunnel’s location


Fig. 8: A view from underneath the Action Zone


Action Zone B is slightly larger than the suggested scale of 5000×5000 (25 “plates”). This can be acceptable within our tech-budget for a few reasons:

  • The area is fairly sparse, with only two major buildings of small size.
  • The area is boxed in by façade buildings, occluding it from other Action Zones.
  • An elevated street helps break up the long, north-to-south line-of-sight.

Fig. 9: The “plate” count for the Action Zones.

Zones Types

Each Action Zone is a defined space where all the game action takes place. For performance reasons, Action Zones should never be placed immediately next to one another. A Transition Zone connects two Action Zones together. This transition area provides a place for new assets to stream in and others to drop out. This also provides a natural reset point for the player, for checkpoints or simple a lull in action. Transition Zones can therefore be considered Safe Zones – a place where the player can rest without fear of initiating an encounter. Geometry in a Transition Zone should be simple and geared towards occlusion.

Safe Zones are one of many zones used to organically describe areas in an Action Zone. Other zones types are Exploration, Puzzle, Chase, and Combat. A Combat Zone is the bread-and-butter to most games these days. Because of their complexity, they can be broken down into two key sub-areas: the Kill Zone (where life is risked) and the Defense Zone (adjacent to the Kill Zone). Satisfying combat can only exist if the player can recognize these two key areas. (The defense zone has been excluded from the example below.) For more info on all these Zones, refer to Level Design Concepts.


Fig. 10: Action Zones and the Transition Zones connecting them.


Fig. 11: How various Zones can describe the Level.


One of the advantages when using prefabs is providing ways for multiple people to work on the same level at the same time. In Figure 12, Action Zones A, B, C have been separated into prefabs letting a Scripter work on Action Zone C, Audio work on Action Zone A, and Art work on Action Zone B. In Figure 13, each building has been isolated into prefabs as well, allowing four different Artists to work on each building, detailing it with models, decals, and lighting.


Fig. 12: External Prefab files for each Action Zone.


Fig. 13: External Prefab files for each Building.

Another advantage to saving buildings in prefabs is re-usability. In addition to audio, prop, and lighting placement, logic can also be added. Doorway triggers, occlusion, vis-portals, navigation, and spawn locations only have to be added one time. Now all these buildings can be used in several places throughout the game without having to re-describe them from scratch! For more info on Prefabs read the article Prefabs: Mastering Massive Content.

Data Nodes

Key areas for various events within the Action Zone are identified with Data Nodes. Examine the Nodes in Figure 15 around the green Shack…


Fig. 14: Node placement overview


Fig. 15: Close-Up of Nodes

In a calm state, AI can randomly pick Idle Nodes to move to. For more controlled movement, connected Patrol Nodes provide a semi-random path for AI to follow. To keep AI within a certain area, it can be assigned a Defend Node. In an alerted state, AI use Alert Nodes to help pick locations to search from. When in combat, a Strategic Node helps the AI find the best place to attack from. A Flee Node is used to guide the AI to an appropriate location, rather than simply running away from a threat. Spawn Nodes are used to bring new AI in to the scene. Lastly, a Scripted Node is a catch-all object to provide any sort of actions none of these previous Nodes provide. All Nodes support animation calls when occupied. Check back for an upcoming post describing Data Nodes in more detail.

Locations and Regions are ways to describe areas in the game through keywords. Keywords help the game systems pick the best place for the requested gameplay.


Locations are the middle man between Data Nodes and Regions. They describe the physical space. Data Nodes become associated to the Location that contains them. When the game asks for to spawn a group of enemies in an alleyway, it searches for the keyword “alley” in all available Regions. If more than one Location is found it picks the best match based on the player’s situation or position. With an “alley” picked, it searches for Data Nodes inside of it to create enemies from.

Locations can be described with its default radius or bound to a volume for hard edged boundaries.

Locations Generic Keywords Cluster Keyword
1 park Junkie_Gardens
2 street
3 alley
4 power station
5 building, small, simple, 1st_floor Hideout
6 plaza
7 building, large, complex, 1st_floor McPawnshop
8 building, large, complex, 2nd_floor McPawnshop
9 building, large, complex, 1st_floor No-Tel_Motel
10 building, large, complex, 2nd_floor No-Tel_Motel
11 building, large, complex, 3rd_floor No-Tel_Motel
12 sidewalk Skidrow
13 street Skidrow



While Locations label a physical place, Regions are a group of Locations that describe a common theme. Regions also help the game pick new locations for missions. When starting a new mission, the game looks outside the current Region to pull the player to a new area.

Like Locations, Regions can be described with its default radius or bound to a volume for hard edged boundaries.

Region Generic Keywords Cluster Keyword
1 (alley, park, street) (Junkie_Gardens)
2 underpass, (power_station, building, small, simple, 1st_story) (Hideout)
3 (alley, building, large, complex, 1st_floor, 2nd_floor, 3rd_floor) Po_Neighborhood, (McPawnshop, No-Tel_Motel)
4 (alley, sidewalk, street) (Skidrow)

(an entry) = inherited from Locations


As stated above, Keywords help the game find the best game space for an event.

  • Regions are groups of Locations sharing a common theme.
  • Locations are groups of Data Nodes sharing a common physical space.
  • Data Nodes are the individual objects the game uses to interact with the world.

Regions and Locations can have these types of Keywords:

  • Generic Keywords – a set list of common Keywords
  • Custom Keywords – an option for adding unique Keywords not found in the common list
  • Cluster Keywords – a special Keyword to help describe a collection of Locations inside of a Region.

The management of Cluster Keywords are through the Location object.

When Regions are resized, they can automatically update what Locations are within their borders. Cluster Keywords are auto-managed by Location association. Because Regions contain Locations, they can list several Cluster Keywords while Locations and Data Nodes can only have one Cluster Keyword.

When Data Nodes are moved outside of one Location and into another, they get automatically associated to a new Location. Data Nodes only have a special keyword called “Ownership” which helps restrict interactivity.


Fig. 18: How Regions, Locations, and Data Nodes relate to one another.


Controllers manage global information for a group of objects. If no specific data is prescribed in the child objects, they inherit settings from the Controller. For example, a Spawn Node can be turned into a Spawn Controller. It has 5 out of 10 child nodes with their Max Amount set to “3”. It manages them with a global Max Amount of “20”. As the encounter unfolds, only 15 enemies can be created at half of the locations (5 x 3). The remaining locations can create an additional 100 enemies (5 x 20) before it reaches its creation limit.

Like Data Nodes, Controllers start as a point-in-space but can be bound to volume(s) to create areas more complex than the default radius. Whether using a radius or volume, they have the option to auto-link any related objects within its area. Regular manual linking can be used for more precision, removing overlapping conflicts, or far away object inclusion.

Example Event

Here’s the chain of game logic events that occur when you pick a mission in a game:

Fig. 19: Example game logic for an encounter.

Directing Gameplay

The game world’s been detailed with pockets of static logic. What’s needed next are the levers that turn on and use portions of that logic to create dynamic gameplay.

Action Zone Activation

A Zone Registry modifies the default values for Action Zone elements. It’s an external file that stores changes to an Action Zone when the larger level (or Action Zone) isn’t active. This allows external events to change the default values, such as Faction control or population choices. A Registry can be modified with game scripting. Registries are usually created during gameplay — the initial values are described in the Zone Controller entity.


Fig. 20: Action Zone event activity.

When the player enters a new Action Zone, the first thing checked is if a Registry is present. If not, then it uses the default values for all Zone elements, such as: music, ambient sounds, light levels, population, a primary and secondary Faction, available resources, vendors, informants, and environment hazards. Gameplay, spawn logic, and other events for key areas are also enabled, waiting to be turned on (or off). When the player leaves the Action Zone all these elements are turned off and disabled. If a value needs to be remembered for a future visit, it’s written to the Registry.

Event Flow

A player has a variety of options while playing. All options eventually break down to individual events. For example, a Mission is nothing more than a series of related events. Enlarge the following chart to understand how events mix into the larger gameplay.


Fig. 21: Player Options & Event flow chart.

Deciding Events

The higher level “brain” that examines all available options and picks the best one for gameplay is the “Decider”. It’s influenced by what’s happening on a per-second basis as well as what larger missions and events have been recently used. Without this piece, manual scripting is required to start correct events for a satisfying experience.


Fig. 22: High level event decisions.

(Credit to Mike Flynn for coming up with the Decider Trifecta!)

Scenarios Examples

With all the mechanics known, let’s show how we can have three different scenarios take place within the same Action Zone.


  • Slums District


  • A highway overpass
  • A couple multi-story interiors
  • A subterranean hideout
  • An ill-tempered power station

Default Settings

  • Faction A occupies one of the interiors and the basement hideout
  • Faction B is invading the area from the north
  • The damaged Power Station randomly arcs electricity
  • Being a populated area, some random loot can be found

Desired Gameplay Options

  • Where, when, and how characters appear and their frequency.
  • Setting Maximum limits for total spawned and total active at any one time
  • Event switches for enabling / disabling spawning
  • Randomize, semi-randomize, and specific spawning locations
  • Action Zone re-use (by changing a few variables)

Populating the Scenario

The Navigation Volume’s preference (which manages NPC desire to be in general areas) is used to help spawn new NPCs. The default modifier for spawning is “only occluded” (don’t appear in plain sight). When NPCs are spawned, their default state is Idle. Idle states naturally seek available Idle Nodes.

So when entering a new Action Zone, population is created “around the corner”. NPCs grab available Idle Nodes (window browse, sit on bench, lean against wall, converse, etc.) to make the Action Zone seem alive.

With this in mind, Navigation Volumes can be used in conjunction with Spawn Controllers to create Event-specific NPCs (Faction AI, Bounty AI, etc.). No Spawn Nodes are needed. If a specific location is needed, spawn nodes can be used to provide an exact point. They can also be used with “ownership” to restrict usage to a specific character (or type of character).

There’s no need for “chair” spawn nodes. A chair can be Idle Node (with a chair model associated to it). When NPCs are spawned they move to available chairs to idle. It’s important to remember data nodes have radius that helps pick an appropriate node that’s not too far or too close to the player or NPC. Some data nodes also have an arrival radius which doesn’t require the NPC to be exactly at the origin point. This can also allow multiple NPCs to use one data node.

Scenario 1 – “Smash n’ Grab”


Showcase initial gameplay…

  1. Infiltrate Faction A’s underground hideout in the Shake.
  2. If you have Informant info, you can bypass some combat by sneaking through the Tunnels
  3. If you don’t, you have to explore the area or fight through the guarded parameter
  4. Another group of Faction A might be in Building A or B, affecting combat and routes.
  5. Once inside, steal the Super Swank Golden G-String
  6. Escape through the front door to meet an escape ship on the roof for Evac
  7. Avoid Faction B at all times.

Scenario 2 – “Return for Takedown”


Come back to the Action Zone and see how things have changed…

  1. Return later to find and capture Faction B’s leader
  2. Flush out Faction B members from the Shack to see which Building they run to
  3. …by overloading their energy source at the Power Station…
  4. Find the best way to enter the correct Building
  5. …by pursuing Faction B guards as they enter…
  6. Capture Faction B leader
  7. Escape via Highway, avoiding Faction A & B

Scenario 3 – “Foxhunt”


Spotlights a chase through multiple Action Zones…

  1. Start in Action Zone A
  2. Pick an entry to Action Zone B
  3. Pick alternative route in Action Zone B to prevent escape
  4. Pick an entry to Action Zone C

Chase Creation

Using the previously mentioned Population Volumes and Data Nodes, scripting a Chase becomes very easy. The target can be is told to path to a destination. That destination can be a specific spot or a semi-random spot by picking a Flee Node at a certain radius from the target’s starting point.

Because the target will pick the path of least resistance (The lowest cost Population Volume), he’ll stick to the main avenues. The player on the other hand can pick alternate routes to catch up. Data Nodes can be used to create a specific route if the Population Volumes offer too much variety.

For more details on making great levels, read PART 3: Level Production.



One Response

  1. Awesome, man! I can’t wait to finish reading this.

Leave a Reply