/Blog: The importance of definitions in game design

Blog: The importance of definitions in game design


The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


 

The games industry is notorious for overloading arbitrary terms used throughout game development. This makes it very confusing when it comes communicating with others. In my personal experience in leadership roles, I’ve encountered the issue of communicating ideas with other designers. I would explain a design our game needed clearly and concisely, but upon receiving the fruits of the request I would realize that what I said was not nearly as clear and concise as I thought.

The team sizes for the games I’ve worked on range from teams of three, up to larger scale teams of thirteen. Being in a leadership role required me to get better at communication with both other designers and other disciplines entirely. In doing this, I learned about the importance of defining terms, and how the more specific the definition is the easier it is to communicate with others.

Imagine working on a team where you’re asked to design a level. The instructions you’re provided with are as follows:

  • Level occurs midway through game
  • Medium in length,
  • Focus on action-shooter gameplay.

 Hopefully this scenario is more extreme than most have experienced, but it’s likely that many designers have dealt with vague instructions like this. I know that I have! Provide five designers with the above instructions and you’ll get five fundamentally different levels. Although different levels from different designers should be expected, having levels that are fundamentally different is bad. Levels must be designed with their sequence in mind, so as to control the introduction of mechanics, rate of difficulty increase, and, hopefully, achieve flow.

How could this happen when the designer was provided with specific criteria to create a level? This is because the criteria are not defined. Even more specific words that lack proper definitions cause issues. If asked to create a long-range combat engagement, the level designer wouldn’t know if that means the level section should have long sight lines, or if placed enemies should rather have long-range weapons. Without specifically defining what a ‘long-range combat engagement’ is, it can be difficult to properly communicate what is needed for the game.

Defining terms early on ensures that all designers are on the same page and can create complementary designs. Once a designer knows that a long-range encounter includes long-range sight lines and long-range enemy types the constructed areas will more closely fit the intended vision. This improves the accuracy of preproduction and builds upon definitions, instead of later deconstructing what has been built and figuring out how to piece them together.

To show an example of what I’m talking about, let’s design a short level for a 1st-Person action shooter game. This game features cinematic narrative moments and areas that facilitate exploration with ammo, health, and lore pick-ups. Let’s first create an intended level flow graph based on two axes: time and excitement.

Time: Measured in minutes assuming the player is playing through an area for the first time and making correct decisions (finding lore pick-ups, not dying in new areas, following the path of progression when presented with forking paths, etc.).

Excitement: Measured in number of enemies a player encounters at a specific time of play.

Chart representing our Level’s intended flow using our defined axes

 

Now that we know our intended difficulty, we have a metric to design our level around. Our level starts easy and reaches its climax 7-8 minutes in. We now have a strong starting point for our level. However, we can go further. Let’s define different types of areas, such as combat areas, exploration areas and narrative areas:

Combat areas: Encourage interesting encounters between players and enemy AI. Contain four or more enemies and prevent the player from progressing further in the level until defeating all enemies.

Exploration areas: Encourage exploration through interesting layouts and prevalence of pickups. Contains three or less enemies, and at least one ammo and health pickup. May contain lore pickups.

Narrative areas: Provide the player with exposition through NPC dialogue. If used to introduce a combat area, this area is considered half as ‘exciting’ as the following combat area.

The above definitions are only an example and should be elaborated upon to fit the specific needs of your game. Additionally, other aspects may be considered such as length (can a narrative area last longer than three minutes? Less than ten seconds?).

Same level flow chart with the appearance of our defined areas added

This exercise has provided us with a lot of information about our level already! Our first area should focus on exploration, with only one enemy perhaps used as a breadcrumb to signify the player is approaching a combat area. Our first combat area has five enemies in it, so it should be smaller than the later combat area which has nine. Our second exploration area needs extra pickups for the player to use to resupply before the last combat area. Additionally, our second combat area must fit between two narrative moments.

This practice can elaborate more within specific area definitions. Here’s an example of breaking down Combat Areas further:

Short-Range Combat Area: 50% or more enemies in this area use short-range weaponry. Short range weapon pickups are found in this area for players to pick up and use. Sight lines should be mostly short (no longer than 15 meters), with several medium (no longer than 40 meters) and no more than one long range sight line (longer than 40 meters) possible.

Long-Range Combat Area: 50% or more enemies in this area must use long-range weaponry. Long range weapon pickups are found in this area for the player to acquire during combat. Sight lines should be mostly long, with several medium and short sight lines. The amount of cover should be sparse enough to discourage players from moving up on enemy positions.

Same level flow chart, but with the appearance of our defined areas added

This above chart now tells us what kind of combat to expect in our combat areas. This is supremely useful for level designers as the first iteration of their level will already be much closer to what is needed for the game! This also makes critiquing the level easier, as the goals of each section of level are clearly defined. (This doesn’t feel long-range enough for a long-range combat encounter.)

Breaking down one’s levels in this way allows for the theme of the level to become obvious. For example, our level has 4 minutes of exploration, 2 of narrative, and 3 of combat. Considering that this is supposed to be an action game, this level has very little of it. This means that this level works best when placed before or after another level that has an abundance of combat. Additionally, this system makes the gameplay theme of a level more obvious. Do we want to have a long-range level? Better ensure most combat areas contain long range combat. This makes it easier for designers to both plan out and theme their levels around these criteria.

I personally used this system when designing the levels for the 1st Person Puzzle game Reflector. By controlling the frequency of narrative exploration areas, versus bounce puzzles, moving platform puzzles, and puzzles that use both, I was able to construct levels that are difficult enough to avoid boredom, but not so difficult that it drives players to quit.

Lastly, this system isn’t exclusive to level design. Defining terms can assist with mechanics design, enemy design, weapons design, and more. On my project Sanguine Soul, we defined our combat loop to assist in the design of abilities and enemies. Figuring out what ‘fast-paced combat’ meant for our game not only made designing easier but made all aspects of the game more cohesive with each other.

I hope you found this blog post interesting or helpful. If you have any comments, please tweet me @LouisMcTague or send me an email at [email protected] ! I also have a website of my game projects found here: http://louismctague.com/