This blog post is a more friendly and accessible version for our paper (by Ahmed Khalifa, Fernando de Mesentier Silva, and Julian Togelius). Also, we added some extra text that got cut from the paper due to the page limit. In this blog post, we discuss six of the most common level design patterns present in 2D videogames that are common and impactful for the overall player experience.
Table of Contents:
Introduction
Many games depend on content variety to tailor their gameplay experience. Having repetitive challenges can lead to player boredom, so designers generally aim to create an experience that is constantly engaging. Games usually consist of many facets such as levels, mechanics, graphics, sounds, etc. One of the most unique is level design. It does not introduce a new dimension in the game, instead, it is concerned with the arrangement of the existing elements. With the high demand for content in games, level design becomes a major task in game design. Its role is of pivotal importance, to the extent of being assigned to a different team than the one responsible for game and mechanics design, for games with large scopes.
When creating levels, innovation and variation alone are not enough to provide quality player experience. Having frustrating scenarios, unclear directions or unappealing challenges are reasons that could lead a level to have a negative impact on players. When observing levels from existing games, it is possible to highlight common patterns that play a part in improving the quality of the design.
These patterns are simple conventions, meant to describe common practices used in level design. Level design is a subconcept of game design. As such, so are level design pattern a subset of game design patterns. However, level design presents many intricacies that stand out inside the scope of game design. The major role levels play in the experience of the game is reflected by the number of resources put into this facet of the design during production. Levels can highlight the story, create smaller short-term achievable goals and help shape the player experience, with the objective of enhancing player immersion. Level creation plays such an important part in a game that sometimes developers provide their audience with level design tools, so they can create and share new levels.
Although the level design patterns we present might be well known to game designers, it is important to formally document them. By doing such, we can facilitate communication between experienced and novice designers, ultimately contributing to the growth and sharing of level design practices. For this purpose, this work aims at formalizing the concept of level design patterns, providing not only valuable resource to novice designers but also groundwork for future study and design of such patterns. It is also our understanding that this work could be beneficial to the research community, especially in the fields of game design, game analytics, procedural content generation, and automated level design.
In this post, we describe in detail six level design patterns. These patterns are noticeable across a variety of 2D games. We discuss the principles and motivation behind applying these patterns and show examples of it being used across multiple games. This work does not showcase all potential or even existing level design patterns, choosing instead to focus on some of the most common, with the intent of formalizing the concept and laying the foundation for future research and discussion to extend upon.
Background
Design patterns date back to the seventies, with origins in the work by architect Christopher Alexander [1]. Alexander created these patterns to find a more formal language to communicate with. The design patterns summarized recurrent problems that could be found in the environment and their respective solutions. The solutions provided worked as guidelines, and not as definitive answers, to the problems shown. This idea was transferred to software engineering in the nineties, when Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published a book discussing software design patterns [2]. Similar to Alexander, they summarized recurrent problems in object-oriented design and suggested respective solutions to them. Kreimeier [3] introduced game design patterns in a similar manner to software design patterns as a way to solve recurrent problems. This definition has changed to be less strict so it views the game design patterns as a common reoccurring game design elements that affect gameplay [4], [5].
Developers, designers, academics, game makers and critics have been discussing design patterns for a long time. Often they are not referred to as design patterns, but as tips, tricks, guidelines, tools of the trade, etc. They usually refer to design pattern concepts by analyzing a certain level or area [6], [7], [7]–[9], game [10]–[22], genre [23]–[31], or being as general as possible [3]–[5], [32]–[42]. That information is usually based on their experiences from designing, developing and playing games. Most notable are patterns that are recurrent across multiple games. We list similarities between previous attempts at cataloging and classifying level design patterns and our own work in the upcoming sections whenever relevant.
In addition to finding and taxonomizing design patterns, studies have investigated how to use such patterns in procedural content generation. Thus, design patterns have been used for level generation [19], [25], [38], [43]–[48], but also in attempts to generate game rules [49], [50]. A common approach is to use design patterns as constraints during generation to limit the generative space to only include levels that make use of them [38], [43], [44], [48], [49]; this is most often seen in constructive generators [51]. Another approach is to use design patterns in fitness functions for search-based generators [52], to guide the search towards levels that utilize these patterns [25], [38], [45], [46], [50], and yet another to include patterns in a training set for a PCGML algorithm [53] to help in generating new content [19], [47].
Patterns
The patterns we discuss are elements that are present in levels across multiple games, rather than being a feature that is recurrent on the same title. To this point, we choose to showcase these with screenshots from different games. We believe that having examples from different sources supports our point that these are valuable concepts with longevity.
Patterns were chosen to take into account their relevancy (if it is often discussed in the community or other works), their recurrence (if they were observed in a substantial amount of the games that were played) and their impact (how important is the pattern in the games that have it). Over 30 Games were chosen to form a representative set, mixing older titles and new ones; published from large companies to independent developers; different gameplaying experiences (such as platforming, racing games, combat-based, puzzle-based, etc); while prioritizing games that are relevant, either from being popular, having a strong community (or cult following) or being commonly referenced as a positive example.
Name | Definition |
---|---|
Avatar | the game entity the players control inside the game. For instance, Mario and Luigi in Super Mario Bros (Nintendo, 1985). |
Boss | an enemy that poses a bigger threat than most. An example is Iceman from Megaman (Capcom, 1987). |
Collectible | a game object that can be collected by the players. An example is the coins in Super Mario Bros (Nintendo, 1985). |
Enemy | a hazard that takes the persona of a character. Goombas from Super Mario Bros (Nintendo, 1985) are one example of enemies. |
Environment Tile | entities used to decorate the game, usually not interactable. Clouds in Super Mario Bros (Nintendo, 1985). |
Hazard | entities that hinder the player from completing their goal. An example is the spikes in 1001 Spikes (Nicalis and 8bits Fanatics, 2014). |
Inaccessible Area | an area that players cannot reach, but that might become accessible at some point in the game. For instance, dungeon rooms in The Legend of Zelda (Nintendo, 1986) that require a key to enter. |
Level | section of the game, where players act towards winning the game. An example is World 1-1 from Super Mario Bros (Nintendo, 1985). |
Mechanic | an element in the game, visible or not, that enforces a rule. An example is the checkpoints in Sonic the Hedgehog (Sega, 1991). |
Object | any entity that appears in a game scene and can change state. It includes hazards, enemies, power-ups and etc. |
Power-up | a collectible that positively impacts the players. The mushroom in Super Mario Bros (Nintendo, 1985) is an example of power-up. |
Projectiles |