Search the Community

Showing results for tags 'items'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Design
    • Projects
    • Design Discussion
    • Tools & Tutorials
  • Off Topic
    • Games Discussion
    • General Discussion
    • Site Support & Feedback

Categories

  • Articles
  • NLD Originals
  • News
  • Projects

Blogs

  • NLD Dev Blog

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 10 results

  1. Edgemister Gaming (@Edgemister) has started up a new level design YouTube series. The first video in this post is an introduction to the series. The second video dives right into the subject matter. Hope you all enjoy! Follow Edgemister Gaming YouTube: https://www.youtube.com/user/edgemistergaming/ Twitter: https://twitter.com/edgemister_ Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  2. About Reaching Perfection Missed Chapter 5? Read it here: Deterrents Intro So sometimes just having the will is not enough to complete the objective at hand. Sometimes you need new weapons, or sometimes powerups will make winning easier. And now that there is danger at hand that wall to your right looks quite appetizing as cover. As you strive to win the game at hand there are many things around a map that encourage you to detour away from your main objective. These things that encourage us to move around... we call them Incentives. More than the obvious Most people understand a base concept of incentives when they think about weapon placement. If you place a rocket launcher here people are going to want to head to it to pick it up, right? Well a sniper rifle or spartan laser isn’t the only thing that can get you to move. Maybe ahead of you there is a turret acting as a deterrent on the main objective path. You see a bunker slightly ahead so instead of being discouraged by the turret’s threat zone, the cover acts as an incentive to continue moving forward. An incentive isn’t always an item, sometimes it is an area or some other type of advantage. The height advantage is definitely seen by many as an incentive to travel up a ramp. Items are just the obvious incentives. Non-existent incentives Now while incentives are great for moving players around a map, some may not be there forever. Most incentives only exist until they are used up. If the only incentive on a path is the sniper rifle, when it is not there then there is no use in going down that path anymore is there? Sure you have the rocket launcher off on the side but that rocket launcher isn’t always going to be there. Using the previous turret example, if no one is on the turret then that bunker is not much of an incentive any more and you can just continue down the center path. A key skill to master when utilizing incentives is taking the time to realize when incentives are turned on and when they are turned off. After mastering that you can follow that up with learning how to effectively control that trait of an incentive by moving players down a path when you want them to go down there and then stopping them from going down there whenever you want. It is a very handy skill to have and one that is well worth the investment in time. That skill alone can fully control the traffic on the map. Taking account for the advantage Something that designers tend to forget is what effect that particular advantage has on the player. When a player picks up active camouflage, do you take the time to consider that he can now travel for a certain distance without being seen? Do you consider that when a player picks up a feather in Mario that they can now fly through the whole level with no opposition? Do you consider that if they gain the high ground that they have full control of this half of the map? It is one thing to offer an advantage to the player. It is another to account for that advantage and make sure that you don’t give the player too much of what they want. Always keep a good balance - any time you give the player an advantage make sure to compensate. If you don’t find that balance then you will end up pulling away from other incentives on the map and pushing too many players to that one incentive. You ever fight over one piece of cake? It’s not pretty. Read Chapter 7: Combat Congestion and Traffic Follow Ray Twitter: https://twitter.com/RayBenefield Mixer: https://mixer.com/RayBenefield Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  3. Follow Neutronized Youtube: https://www.youtube.com/channel/UCHZkLi-4lIASVlMP-Edq1jg Twitter: https://twitter.com/neutronized Website: http://www.neutronized.com/ Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  4. This article is a portion of a dissertation by Kenneth Hullet. The source writing is over 250 pages in length. We share this in hopes that it will further the learning of level designers. The Table of Contents is listed directly below, within a spoiler. The parts marked in Orange are included here. Follow the link at the end of this article to read the full writing, as it contains much value. TABLE OF CONTENTS - In Spoiler ABSTRACT Level designers create gameplay through geometry, AI scripting, and item placement. There is little formal understanding of this process, but rather a large body of design lore and rules of thumb. As a result, there is no accepted common language for describing the building blocks of level design and the gameplay they create. This dissertation presents a set of level design patterns for first-person shooter (FPS) games, providing cause-effect relationships between level design patterns and gameplay. These relationships are explored through analysis of data gathered in an extensive user study. This work is the first scientific study of level design, laying the foundation for further work in this area. Data driven approaches to understand gameplay have been attempted in the past, but this work takes it to a new level by showing specific cause-effect relationships between the design of the level and player behavior. The result of this dissertation is a resource for designers to help them understand how they are creating gameplay through their art. The pattern collection allows them to explore design space more fully and create richer and more varied experiences. INTRODUCTION Level designers create gameplay through geometry, AI scripting, and item placement. There is little formal understanding of this process, but rather a large body of design lore and rules of thumb. As a result, there is no accepted common language for describing the building blocks of level design and the gameplay they create. This research creates a science of level design based on design patterns for first-person shooter (FPS) levels and data analysis to show cause-effect relationships between level design patterns and gameplay. Level design is often viewed as an artistic endeavor, so the applicability of purely scientific approach may be considered controversial. This research argues that level designers employ design patterns while creating FPS levels, whether advertently or inadvertently. Furthermore, analysis of gameplay data can show distinct patterns of behavior in different situations. If we control for all factors besides the design of the level, we can claim that significant observed differences are due to the level design. To show these cause-effect relationships, we conducted a user study and performed analyses of the collected data. The user study explores what effects the patterns, and variations within the patterns, have on players’ in-game behavior. Based on deviations from the expected results, we are able to adjust the theory, improving our understanding of the relationships, and increasing the usefulness of the taxonomy as a tool for level designers. For each pattern explored in depth, we created multiple instances of the pattern, each with a different set of affordances – for example, with a sniper location, some instances were high, some low, some with good cover, some without, etc. Based on our surveys of existing FPS level design, we expect a lower sniper location to have less of an effect on the level’s pacing; we should observe less of an effect than we would when subjects encounter a higher sniper location. These instances are placed in the user test levels played by the subjects. From the data collected during the user study we can determine how gameplay is affected by the pattern, and if this is different from what we expect. This research is necessarily reductionist in its approach. In practice, design patterns are rarely distinct, instead overlapping with other patterns or elements to create varied effects. Nonetheless we will argue that design patterns provide a useful analytic framework for thinking about level design in a scientific way. The lowest possible segmentation of level design elements, the actual placement of individual walls, floors, items, and entities, is far too granular to elicit any understanding of designer intent or to observe an effect on player behavior. The highest level, a complete level, is far too coarse, as FPS levels generally contain multiple subareas with different gameplay objectives. Design patterns are a small enough unit that a clear distinct purpose can be elicited, but not so small as to be overwhelmed with details of pixel by pixel placement of objects and geometry. THE FIRST-PERSON SHOOTER GENRE FPS games are combat-oriented games where the player engages other characters with a variety of projectile and melee weapons. The player navigates a 3D world while looking through the eyes of the main character (i.e., a first-person point of view), though some games where the camera follows the player character (third person shooter or TPS) have similar gameplay and are generally considered to be in the same genre. FPS games are one of the most popular genres of commercial digital games, with many published titles on multiple platforms. Seven of the top-ten all-time best-selling games for the Xbox 360 are FPS games. Due to the processing power needed to render realistic-looking 3D environments, FPS games are often credited as a driving force behind technological advancement in personal computers and gaming consoles. Beyond entertainment, FPS games have been used for a variety of training and other serious game applications. One of the most notable is America’s Army, a training and recruitment game released by the US Army. Its intent is to provide a realistic simulation to familiarize recruits with modern Army combat procedures. The platform has been used as the basis for more advanced Army training programs. As a popular and broadly relevant genre, any research that improves our understanding of FPS games is likely to have significant impact. There is also a large body of in-depth analysis which can be drawn upon, including books and articles on FPS design in general and level design specifically. While the results of this study are specific to FPS games, the techniques we propose are generalizable to other game genres. FPS games are also a desirable genre for this study as the level design is a major component of the game and has a significant impact on the player's experience. Levels in commercial games are designed largely by hand and play tested extensively by designers to create specific gameplay effects. It would be difficult to conduct research of this nature on a genre of games where the level design was not as impactful. Furthermore, while the player's experience is by the level design, the mechanics of the game allow for enough variation in individual choice that these impacts are apparent. For this research, we have chosen to focus on single-player levels, though multiplayer is increasingly becoming the dominant gameplay mode. In multiplayer, players are generally playing against other players, rather than environmental challenges created by the designer. For this reason, it would be more difficult to conduct an experiment like the one described here for multiplayer levels. However, it is likely that level design does have an impact on gameplay in multiplayer FPS. Early exploration of patterns specific to multiplayer level design is described in Appendix A. LEVEL DESIGN The precise definition of a level varies by game and genre, but it is generally thought of as a subdivision of a game. Specifically, it is a space where gameplay occurs. While the mechanics of the game define the choices available to the player, the design of a level defines what the player experiences at any given point. It is through level design that level designers craft gameplay experiences for players. Levels for FPS games are generally designed for single- or multi-player play, but not both. Single player levels tend to be a linear sequence of challenges the player must overcome to reach the final goal, whereas multi-player levels are designed to create areas for player-vs.-player combat to occur. While level geometry is the most noticeable aspect of the level designer’s work, other considerations are important in the creation of gameplay. Level designers place objects in the world, including weapons, ammunition, and power-ups. They must be sure to provide enough so the player can complete the level, but not so much as to remove all challenge. They also place Non-Player Characters (NPCs), both friendly and enemy, and use AI scripting to control their behavior. When designing an FPS level, there are many factors the designer must consider, including challenge, pacing, and ease of navigation. Though many FPS games have been made, and numerous books have been written on the subject, there is little formal understanding of their level design. The existing literature conveys design lore and industry practice without exploring how levels create gameplay. Experienced level designers draw from their extensive knowledge of existing games when they create a level. They have an intuitive feel for what features they should include in a level to create different types of gameplay. They may imitate and adapt elements they’ve observed in other levels. Presently, there is no structured way for experienced designers to pass on this knowledge to less experienced designers. A more formal framework would improve designers’ abilities to communicate design ideas as well as provide a reference for possible features to incorporate into levels. For example, one of the design patterns identified is a sniper location. This is an elevated position from which a character can engage other characters in relative safety. There are numerous variations on sniper locations, including their height, amount of cover available, and whether it is intended for use by either the player or an enemy NPC. The effect of an enemy NPC-occupied sniper location is to slow the pace of the level – the player must move slowly and be more cautious to avoid taking fire. While we can predict this behavior based on our understanding of FPS gameplay, it is unknown if the effect is consistent in all cases, or how it is affected by variation within the pattern. Would the effect be less if the sniper location was lower, as it would be easier for the player to engage the enemy NPC? User tests where a number of subjects play levels with different instances of sniper locations will provide empirical evidence of these relationships. The taxonomy of design patterns is a useful tool for improving designers’ abilities to communicate design ideas and as a reference for possible features to incorporate into levels. However, the process by which it was created is necessarily subjective. Designers’ intentions in using certain features may vary, and how players react to the patterns may vary. DESIGN PATTERNS As described above, our user studies are focused on single player levels. While we have explored design patterns in both multi- and single player levels, level design necessarily has a greater impact on single player gameplay, as the players' only interaction is with the environment, rather than with other players. As such, this research is primarily focused on the design patterns developed from analysis of single player levels. The patterns are described in terms of their intended use, effect on gameplay, and variations within the pattern. Examples from popular commercial games are given. The use of design patterns to describe levels is inspired by design patterns used in both software engineering and architecture (the latter of which also inspired the former). A set of design patterns form a language for describing design practices in the domain. Duffy et al. characterize patterns in software engineering by the following: “Noticing and naming the common problems in a field of interest, Describing the key characteristics of effective solutions for meeting some stated goal, Helping the designer move from problem to problem in a logical way, and Allowing for many different paths through the design process.” This research adapts these characteristics to the domain of level design in FPS games. For level designers the problem is creating an entertaining and engaging experience for the player, and the solution is in how they design the level. We adapt the above to define characteristics of a pattern language for the domain of level design, described in detail below: Noticing and naming common structures that produce specific types of gameplay The taxonomy presented in this dissertation was created by identifying design patterns in levels and the gameplay they produce. Examining existing levels and inferring the intended gameplay is the most common means of identifying design patterns, but other methods were employed, including interviewing designers about how they design to elicit certain types of gameplay and reading books and articles that describe common practices. Describing the key characteristics of these structures and how they affect gameplay In identifying the patterns, we noticed that significant variations exist within any given pattern, and those variations have an impact on the gameplay produced. As examples of patterns are identified, variations and their effects are noted, resulting in a more complete detailed view of the pattern and its parameters. Helping the designer address level design concerns in a logical way Armed with knowledge of level design patterns, the designer can tailor a level to the desired gameplay. For example, if a designer wants to change the pace of a level, they can add or alter instances of patterns that are known to affect pacing. If, during gameplay tuning, they discover a problem in a level, they can use the taxonomy to modify existing patterns to address the issues. Allowing for different approaches to create the desired gameplay The taxonomy identifies different design patterns that will affect gameplay in similar ways. If the designer wants to create a certain type of gameplay, they can identify multiple elements in the taxonomy that would be suitable, and pick one that is appropriate for that instance. They are not limited to repeatedly using the same patterns in the same ways; they can use different patterns, or variations with patterns. RESEARCH QUESTIONS The goal of this research is to use data analysis to develop the science of level design through a deeper understanding of FPS level design and how it creates gameplay. The research questions can be broken down into questions about design patterns, player behavior, and the applicability of the work. RQ1: Are level design patterns useful for developing levels, communicating ideas, and teaching about level design? We have already identified level design patterns to create a language for describing levels. The application of design patterns to FPS levels and the patterns themselves are described in Chapter 3. These descriptions provide insight into the designer’s intent and the gameplay that will result. It should be possible to take an existing level and describe it extensively in terms of design patterns. We give an example with a level from Bioshock, a popular commercial FPS. Such description often reveals sections of a level that are not describable with the existing taxonomy, leading to the elicitation of a previously undescribed pattern. Through study of FPS levels we can improve and expand the pattern collection. Besides expanding the pattern collection, it is important to validate the effects of the patterns. The results of this study have helped close the loop and improve the descriptions of the patterns and their gameplay effects. The end result of the study is a set of patterns that has been shown to create specific behavior in the player. RQ2: Can we use data analysis to understand player behavior in FPS levels? To test the cause-effect relationship of the patterns and their variants on gameplay, it is necessary to understand player behavior. What exactly does it mean, for example, when the tension of a level is increased? How is this reflected by the player’s in-game actions? Can this be observed and reported? While previous user studies provide some guidance, it was necessary to develop methods for identifying and classifying player behavior. How this was done in this research is described in Chapter 5. Subjects’ in-game behavior was studied in the video recordings of their level play-throughs and the logged gameplay data. This was correlated with the pattern variants that the subjects encounter to see what the effects are. RQ3: Do the identified design patterns and their variants create the intended gameplay effects? Patterns are used in levels to affect gameplay – for example, when a player encounters a choke point where they have an advantage over enemy NPCs, the expectation is for increased pace and reduced challenge. This should be reflected in the player’s behavior by traits such as engaging enemy NPCs more aggressively, using weapons more frequently, making less use of cover, and moving more quickly. In validating these relationships, we are developing the science of level design. Chapter 5 describes the user study we ran to explore these cause-effect relationships and Chapter 6 explains the results of the analysis. If the expected behavior occurs when a player encounters a design pattern variant in a level, then the theory is validated. In the example above, when the player encounters the choke point, their behavior should be close to our expectations. If for some variation of the choke point, they instead begin moving more slowly and playing cautiously, then there is something about that instance that is creating different gameplay. We can identify what affordances of the pattern vary from other instances and adapt the pattern description to match the observed results. To fully explain the impact of this research, this document is broken into multiple chapters. Chapter 2 covers related work in the existing literature on level design and data analysis in games. Chapter 3 presents the taxonomy of design patterns that we have developed for this research. Chapter 4 explains the major sources of data in games and their impact on game development. Chapter 5 describes the user tests performed, and Chapter 6 details the results. Chapter 7 summarizes the findings and the contributions of the research. RELATED WORK There are three broad streams of work related to this research. First, previous work on applying design patterns to games in general and level design specifically. Second, previous work on exploring, understanding, and communicating about level design in general, mostly from an industry perspective. Third, previous work on understanding player behavior and how data analysis can be used to identify such behavior. These three areas are described below. DESIGN PATTERNS The use of design patterns to better understand levels is inspired by their use in software engineering, which were in turn inspired by design patterns in architecture. Kreimeier was among the first to adapt the concept of design patterns to the domain of digital games by identifying game design patterns. Björk et al. extend this work by studying how players interact with games and how entities in a game interact with each other. They identify over 200 patterns in game design ranging from the basic building blocks of games, such as the game world, to abstract concepts like player collaboration and immersion. The patterns are organized in broad categories such as “Patterns for Goals” and “Patterns for Narrative Structure.” Patterns are described in terms of how they are used, the choices a designer must make when using them, their consequences and relationships to other patterns. These patterns do not specifically deal with level design, but do relate to some level design concerns, such as balancing, goals, locations, and objects. For example, one pattern identified by Björk et al. is Pick-ups, described as “elements that exist in the game world and can be collected by players.” They go on to describe how pick-ups are used in a variety of games and the considerations a designer must make when choosing whether to include them or not. They describe general consequences of pick-ups, but they do not describe the immediate effects they have on a player’s behavior or the flow of a game. The level design patterns presented in this dissertation address these considerations. Björk et al. suggest four ways patterns can be used to support game design: idea generation, structured development, solving design problems, and communication. The level design patterns identified in this dissertation support these same uses. Another application of design patterns to games is Plass et al.’s study of educational games. They identify common patterns in educational games that increase enjoyment and engagement in players. These are high-level conceptual goals for designers to pursue, not patterns of mechanics as in Björk et al.’s work, or patterns of level design as presented in this dissertation. Examples include “Constructing things is fun and helps learning” and “Time and resource constraints make games fun and can improve learning.” These patterns were discovered through observational studies and interviews with children playing educational games. LEVEL DESIGN There are many books on level design written from an industry perspective. They discuss common practices and provide instruction on tools for aspiring level designers. In his book, Co takes the reader through the process of designing an FPS level, from brainstorming initial ideas, building the level using Unreal Editor, to testing and improving the level [6]. While useful references, neither this work, nor similar books by Bryne, Clayton, or Feil et al. present deep analysis of how level design creates gameplay. For example, Feil et al. describe the importance of overall pacing in a level. They discuss how a rhythm of rising and falling tension can contribute to the overall flow of a level without providing methods for creating these effects. Similarly, they discuss strategic considerations of terrain, such as access and height advantage, but do not discuss how they create gameplay. In contrast, the work presented in this dissertation provides specific, concrete idioms of level design described in terms of their direct impact on gameplay. Several shorter works examine single aspects of level design, from both academic and industry perspectives. The aspects examined can be broadly categorized as relating to gameplay – pacing, tension, and challenge – or space – spatial configurations and how the player navigates. PACING Pacing is the density of actions taken by the player in a level. Coulianos proposes methods to analyze and improve level pacing. Designers can plot the expected pacing as a sequence of gameplay elements. Playtesting can then be used to see how closely the player’s experience matches the designer’s expectations, leading to a series of iterative changes until the designer is satisfied. Davies also explores aspects of level pacing and suggests techniques designers can use to control pacing. For example, the player’s impetus to move is a key aspect of game pace, which the designer may want to increase or decrease. Movement impetus can be increased by elements such as a time limit or a threat from behind, or decreased by an obstacle or NPC interaction. TENSION Tension is the mental strain a game can create in the player as they struggle to survive or complete objectives. Level designers use tension to affect pacing. For example, NPCs can create tension by urging the player to move through the level faster. Its use is examined in depth by Wright, who conducted a study with subjects playing one of three levels that used NPCs to create tension differently. Completion times as well as the subject’s subjective impressions were compared to evaluate the methods. He found that urgency imparted from a friendly NPC was the most effective method, while chasing or being chased by enemy NPCs were less effective. CHALLENGE In his study of what makes games fun, Malone identified three main elements: challenge, fantasy, and curiosity [18]. All three of these are useful to level designers, but challenge is the most critical. Malone found the best way to create challenge is to provide clear goals whose attainment is uncertain. If the goal is unclear, the player will become frustrated. If the goal is too easy to attain, the player will become bored. Furthermore, if the goal is long range, there should be feedback given to the player that communicates progress towards the goal. SEGMENTATION Segmentation is a broad concept that can be applied to the examination of levels both in terms of gameplay and space. It refers to methods for breaking down aspects of the game into smaller elements. Zagal et al. describe three types of segmentation: temporal, spatial, and challenge. Temporal segmentation is closely related to pacing, as increasing or decreasing the length of time allowed for gameplay can affect tension and challenge. In terms of spatial segmentation, levels themselves are a form of this, but they can be segmented internally as well. As a player moves into a distinct section of a level, their behavior may be affected. For example, moving into a large arena with enemy NPCs will increase tension and difficulty. The third type of segmentation, challenge, also relates to pacing. Breaking up the challenges presented to the player allows the designer to control the level pace. SPATIAL CONFIGURATIONS Within spatial segmentations, the configuration of the environment is also a key concept in level design. Chen et al. compares level design to the architectural design that is used in real world buildings. When designing a building, the architect includes architectural devices to create specific effects, such as customizing a space to a particular use. The authors identify some architectural principles that level designers can apply to create spaces for gameplay, including having a clear path through the level, how to use different spatial organizations such as linear or hub and spoke, or including unique elements to break up the design. An examination of how space is used in team-based multi-player FPS levels was presented by Güttler et al. They identified common spatial configurations and how they contribute to gameplay. The key elements they studied are collision points and tactical choice. In a team multi-player level, the designer provides multiple routes through the level, allowing players the chance to make a strategic decision. The choice of route determines where in the level the two teams will eventually clash; these collision points are the major contested spaces where the game is played. There are some significant empirical studies that evaluate the effects of level design on gameplay. Gee studied the use of dead-ends in FPS levels. He identified ways in which dead ends are used and built example levels that included them or not. Subjects were observed playing levels and their preferences and playing time were reported. Results indicated that dead ends did not negatively impact FPS levels. An empirical study by Gonzales explored directional choices in FPS levels. Similar to the Gee study, they identified different techniques for presenting alternate routes and performed user studies on a set of representative levels. Survey responses and subject observations contributed to their conclusion that choice improves player immersion, as the lack of choice in a linear level can break the illusion of being in large, dynamic world. NAVIGATION A key use of spatial configuration in levels is in providing navigational cues to the player. This is particularly true in FPS levels as they are generally large, complex environments. Nerurkar examines some means level designers use to aid player navigation. Some, such as maps and navigation markers, are separate from the level design, but many are a function of the level design. Examples include features that attract the player’s attention, use of light and contrast, and directions from NPCs. Hoeg performed an empirical study of player navigation and player types in FPS levels. He identified elements that designers use to influence pathing decisions, including lighting, sound, and resistance, and formed a theory about how Bartle’s player types would react in each case. He constructed a level with multiple decision points, using different navigation cues. Subjects’ player types were determined by a survey, and their routing choices were recorded while playing the level. The results were compared to see if the theory was consistent with the player’s behavior. They found that some elements, such as placement of doors and motion, had strong correlation, whereas other factors had weak or no correlation. DESIGN PATTERNS While our user study is primarily focused on the effects of design patterns in single player levels, we explored design patterns in multiple aspects of FPS games. Of particular relevance are the patterns for combat NPCs and for weapons. Weapon and NPC design in FPS games fall into a grey area between game design and level design. While they are aspects of the game mechanics, and therefore game design elements, they are greatly influenced by the work of the level designer. Tuning of weapons and NPCs generally occurs late in the development process, and is a function of the constructed levels. As the final tuning of these elements are dependent upon their placement and use by level designers, they can be considered an aspect of level design. As such, patterns for these elements are described here along with the single player patterns. Other pattern collections are presented in Appendix A. SINGLE PLAYER FIRST-PERSON SHOOTER LEVELS The descriptions of the patterns explain how they can be used, the concerns designers must address, and the gameplay created. The fields are listed below: Description – A high level description of the pattern and the major design considerations. Affordances – Aspects of the pattern that can be varied by the designer. Consequences – A description of the gameplay the pattern creates. Relationships – Some examples from popular commercial games that illustrate the pattern. The use of the term "affordances" in this research is a bit idiosyncratic. In the field of design, the word typically means "the perceived or actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used." For example, the presence of a doorknob is an affordance that signals that a door may be opened. For this research we modify this definition slightly, so affordances are aspects of a pattern that can be varied by the designer ("perceived or actual properties") to alter the effect on gameplay ("how the thing could possibly be used"). Essentially, affordances are the knobs a designer can twist within a pattern to dial in different gameplay effects. The patterns are grouped into one of four following categories based on the type of gameplay produced. The categories are Positional Advantage, Large-scale Combat, Alternate Gameplay, and Alternate Routes. These distinctions are not mutually exclusive, a pattern might be perceived as being in one category or another based on its affordances. Furthermore, specific patterns may overlap, resulting in different effects and described in the relationships sections of each pattern. Positional Advantage – Spaces where one entity has an advantage over another. Sniper Location – A protected, elevated location that overlooks some portion of the level. Gallery – An elevated area parallel and adjacent to a narrow passageway. Choke Point – A narrow area with no alternate routes, causing entities to be exposed to engagement as they move through. Large-scale Combat – Areas designed to facilitate combat involving large numbers of entities. Arena – An open area or wide corridor. Stronghold – A confined area with good cover and limited access points. Alternate Gameplay – Introduce new elements that break from the established mechanics of the game. Turret – An area with a high-powered weapon where one side has a clear advantage. Vehicle Section – Sections of alternate gameplay where the player drives or rides in a vehicle. Alternate Routes – Create alternatives for the player in how they approach the level. Split Level – A corridor with an upper and lower section, where those on the upper section can attack those on the lower section. Hidden Area – A small area off the main route that contains items for the player. Flanking Route – An alternate path that allows characters to gain positional advantage. PATTERNS FOR POSITIONAL ADVANTAGE These patterns all result in one entity gaining an advantage in position over another entity. A positional advantage usually affords opportunities to attack other entities without being exposed to counter attack. SNIPER LOCATION Description: Sniper locations are one of the most common patterns. A character in a sniper location can attack other characters with long-range weapons while remaining protected. Any elevated position that overlooks some portion of the level is potentially a sniper location. They may be intended for use by either players, NPCs, or both. Creating a sniper location for use by an enemy rather than the player requires additional consideration. Enemies positioned in the sniper location may require special scripting to create the desired behavior; they should remain in place, using cover if available, and engage the player with long range weapons. Affordances: The height of the sniper location over the main part of the level How large of an area is available for the sniper The amount of cover available for the sniper The size of the area that the sniper can cover from the sniper location How accessible the sniper location is from the area overlooked Consequences: When confronted with an enemy sniper location, the player is forced to make careful use of cover or seek alternate routes to avoid being exposed to fire. This can increase the tension and slow the pace of a level while creating a challenge for the player. A player sniper location generally slows the pace of a level while lowering tension as the player is able to engage enemy NPCs without being exposed to enemy fire. However, if the sniper location is not isolated from the rest of the level, the player will have to defend the access point as well, increasing tension. Relationships: Sniper locations interact with many other patterns. They may be placed to cover an arena or a choke point. Most stationary turrets are also sniper locations. A shooting gallery is specialized type of sniper location. A sniper location with access may be a type of stronghold. Examples: In the level “Route Kanal” of Half-Life 2, the player encounters an enemy sniper location, shown in Figure 1. It is high above the player’s position, but has very little cover. The player can engage the enemy NPCs, but is exposed and needs to be cautious. Figure 1: Sniper location in Half-Life 2 There is a sniper location in the level “Corinth River” of Killzone 2. The player is on an elevated walkway overlooking a medium-sized area containing enemy NPCs. Both the player and enemy NPCs have cover, but by looking down from above, the player is able to locate the enemy NPCs and engage them. PATTERNS FOR LARGE-SCALE COMBAT These patterns provide areas for combat gameplay, with the player either engaging large numbers of enemy NPCs or a single powerful enemy NPC (a boss fight). STRONGHOLD Description: A stronghold is a confined area, generally with good cover. Characters in a stronghold can defend against attackers while remaining protected. A stronghold has limited access points so the defending characters can cover them easily. Affordances: The size of the stronghold The amount of cover available in the stronghold The number and type of access points If defending/capturing the stronghold is a level objective Consequences: Generally a stronghold would be designed as a defensible location for the player. The effect is usually to reduce the pace of the level, but in some cases, a large number of entrances or advancing enemy NPCs can have the effect of increasing tension and challenge. Relationships: A stronghold can be considered a specialized type of arena or sniper location. Entrances to the stronghold may be choke points. Examples: The Halo 3 level “The Covenant” contains a stronghold. The player is in a large open area and engages enemy NPCs entering through multiple entrances. These entrances are choke points that help keep the player from being swarmed by enemy NPCs, but it is challenging to cover them all at once. There is an instance of a stronghold in the level “Fish in a Barrel” of Gears of War, shown in Figure 2. The player and friendly NPCs are in a central area with minimal amounts of cover while being engaged by enemy NPCs from multiple directions. The effect is challenging and high tension combat. Figure 2: Stronghold in Gears of War PATTERNS FOR ALTERNATE ROUTES These patterns provide players with choices about how they want to engage the level. SPLIT LEVEL Description: A split level is a corridor with an upper and a lower section. Characters on the upper section can attack characters on the lower level. Players can choose the upper or lower route, or switch between them. Affordances: The difference in height between the levels The degree of openness between the levels, in terms of empty space The number of paths between the levels Consequences: Allows for different strategies and can increase the pace of a level as the player moves back and forth between levels. Relationships: If the corridor is narrow, the upper section could be a gallery. Using one section to avoid enemy NPCs in the other section makes it a type of flanking route. Examples: There is a split level in the “Lowlife” level of Half-Life 2: Episode 1, shown in Figure 3. The player is moving through a large open area with elevated passageways. The player must switch back and forth between the two paths to avoid the most powerful enemy NPCs. Figure 3: Split level in Half-Life 2: Episode 1 The Halo 3 level “Crow’s Nest” features a long split level section. The player may stay on the upper level and engage enemies on the lower level, or use the lower section and engage them directly. COMBAT NON-PLAYER CHARACTERS IN FIRST-PERSON SHOOTER GAMES - The work presented in this section is based on material originally developed in collaboration with Gabe Rivera. The patterns presented in this section are for the enemy NPCs in FPS games. Enemy NPCs are controlled by the game engine and are the main source of conflict during gameplay. While they could be considered aspects of game design rather than level design, they are placed by designers and their tuning and behavior are highly dependent on how they are used. Designers can control not only where the NPC is placed but also the NPC’s scripted behavior, how they are equipped, their level of health, their level of armor, and other variables. For this research we explored elements that pertain to all NPCs within the shooter genre and then analyzed various games to see if NPCs consistently fell into patterns. Patterns were identified by observing NPC behavior and discerning which elements were combined in the same way within a number of games. Each pattern is accompanied by our observations about how it’s used by designers to create gameplay, as well as a list of elements that define the pattern. ELEMENTS OF A NON-PLAYER CHARACTER Below is a list of elements that make up a NPC as well as a brief description of how they can be used by a designer to create gameplay during combat. These will be used in the pattern collection to categorize the specific patterns. Movement Type – This describes the way the NPC will typically move in a combat situation. Many NPCs employ multiple Movement Types and can switch between them depending on the situation. Flanking Intensive – The NPC will move to attack from unexpected directions, i.e. the NPC tries to approach the player from a different side than where the player’s attention is directed. Passive – The NPC will not move when attacking. Never straying too far from that location and available cover. Slow Push – The NPC will slowly advance on the position of the opposing force, usually in a straight line. This can be without the need for cover, but it is possible for the NPC to utilize cover while making its way forward. This main difference between this and Cautious is that it will constantly try to close the distance from its target and not try to stay away. Rush – The NPC will make a dash at a specific target without any regard for their safety, typically in a straight line. However, the main aspect of this movement type is that they will attack very fast and often try to close the distance between themselves and their target as fast as possible Cautious – When used, it means that the NPC is opting to move around the battlefield but tries to maintain a distance from its target. Often trying to utilize cover when possible and not closing the distance when possible. This is different from a slow push because this NPC tries to maintain a specific radius around its target, without advancing. Movement Range – This is how far the NPC will move during an engagement. This can be Low, Medium, or High. Movement Frequency – This is how often the NPC will change their position during an engagement. This can be Low, Medium, or High. Attack Frequency – This describes how often the NPC will initiate an attack. This can be Low, Medium, or High. Weapon Type – The patterns include the following. They are described in more detail in the following section: Sniping Weapon Close Blast Assault Weapon Projectile Power Weapon Melee Weapon Weapon Damage – A general indicator on how much damage the NPC will do to the player’s Health, Shields, or Armor. This can be Low, Medium, or High. Armor/Health – This denotes how much damage the NPC can take before being killed. This will typically be linked to how hard the NPC is to defeat. This can be Low, Medium, or High. Motive – This is an indicator of what type of combat encounter the NPC would create and shows its purpose to the designer. This hinges on three main factors that an NPC can affect: Challenge – The degree of difficulty within a combat encounter. Tension – The degree of mental stress the player experiences during a combat encounter. Pacing – The degree of movement that the player will engage in during a combat encounter A pattern can affect each of these three factors by creating a situation where they can be at Low, Medium, or High. PATTERN COLLECTION Below is a list of all the patterns that we have collected during our research. Each base pattern specifies the primary function of that general type, while each sub pattern denotes how that function is carried out. Soldier – An NPC that pressures the player from range. Grunt – A weak enemy that attacks from a medium distance, often in groups. Elite – A strong enemy that works to contain the player from a medium distance. Grenadier – A weaker enemy that maintains long distance to encourage players to move forwards. Sniper – An enemy that deals high damage from a long distance to force players to move carefully. Aggressive – An NPC that attempts to close the distance between itself and its target in order to increase pressure. Suicide – An enemy that immediately rushes at the player, at the cost of its own life. Swarm – An enemy that rushes the player in groups, but deals low damage individually. Berserker – A strong NPC that deals a high amount of damage over a prolonged amount of time. Carrier – An NPC that will spawn more NPCs during an encounter. Sacrifice – An NPC that creates more NPCs in the case of its own death. Summoner – An enemy that spawns more NPCs at a distance Tank – An NPC that poses a significant singular threat and prevents the player from proceeding Stationary Tank – A slow-moving NPC that deals high damage at a long range. Shield – An NPC with a large amount of armor, but only in a single direction. The following sections detail all of the base patterns and at least one of their sub patterns. SOLDIER Soldier is a NPC that will pressure the player from long range. Its main strategy is to control the available space in the encounter. NPCs of this type make up the majority of units during an encounter. They are primarily used to control pacing by forcing the player to take particular paths through the environment. These NPCs will have a weapon type that is an Assault, Close Blast, Sniping, or Projectile. Grunt Description: The Grunt is a weak NPC that will try to maintain a medium distance away when attacking. The main function this serves is to draw the player to forward through the level and increase the player's confidence. This pattern is distinguished by always having medium movement range, medium movement frequency, and light armor. The motive of the Grunt pattern is to create a situation with low tension and low challenge. Affordances: Movement type can be Slow Push, Flanking Intensive, or Cautious. Attack frequency can be either Low or Medium. Weapon damage can be either Low or Medium. NPC Relationships: The grunt has a special relationship with the Suicide pattern, because sometimes a grunt may change to the suicide pattern in the middle of an encounter. Examples: Halo: Combat Evolved - The Grunt is a small unit that appears in every game within the Halo franchise. It has a low amount of Armor and is usually to be equipped with an assault weapon that does a low (Plasma Pistol) or medium (Needler) amount of damage. They exhibit the special relationship with the Suicide pattern in that they will self-destruct in times of desperation. The range it keeps is either short or medium but tries to pester the player by implementing the Cautious movement type. During the campaign they primarily occur within encounters to create a lower challenge but increase the pace of the encounter. As a consequence, the player feels more empowered and will pursue a route that contains a higher ratio of grunts compared to any other path. This occurs in the level The Pillar of Autumn; often the designers put grunts down a particular corridor to encourage the player to move in that direction. This signals to the player that it is the correct route to follow while lowering challenge, increasing the pace, and lowering player tension. Figure 4: A Group of Grunts in Halo: Reach Half-Life 2 - The Metro Police Officer utilizes a Slow Push or Cautious Movement Type and primarily is equipped with an assault weapon, typically a sidearm. They will shift between the movement types in an effort to move a player forward. Typically this means that they will begin in a cautious movement type and, if they player doesn’t pursue them, will move toward the player in order to get the player to move. This doesn’t occur in any particular instance but can be seen where there are Metro Police Officers in levels such as Route Kanal or Water Hazard. In the game, they basically act as bait to simply pull the player forward. They are primarily seen as the main enemy in the early game and are increasingly used as bait in the latter half of the game. Figure 5: Two Metro police officers in Half-Life 2 EXAMPLE ANALYSIS To show the usefulness of NPC design patterns we will use them to analyze a short encounter and generate a new enemy type. The level Winter Contingency in the game Halo: Reach contains an encounter in which the group is tasked with bringing a communications outpost back online. This sequence starts with the team landing in front of the communications outpost in order to secure the location. After starting the level, the player encounters their first group of enemy NPCs in an Arena with Flanking Routes to the left and right. The NPCs that populate the arena are a small force of Grunts and Jackals. This encounter has a low amount of challenge and allows the player to gain a foothold without much effort. It is fairly easy for the player to move forward and incapacitate the Grunts, which fall under the Grunt NPC pattern. However, it is much harder kill the Jackals in a head on attack since they are a part of the Shield NPC pattern. The interplay between the Grunt and Shield patterns help to create a much easier encounter for the player by driving them to explore the area and flank the Jackals. The player goes into the encounter and immediately recognizes that most of the Jackals were located in the Arena, where the player is at a disadvantage. Since that place is the hardest to break through, the player is drawn to the left because the Grunts offer a lower level of resistance. The Grunts signal to the player this path is safer and encourages them to move through the Flanking Route. The player can now flank the exposed back of the Jackals, which has a pattern specific weakness of only being able to withstand a large amount of damage from one direction. We can analyze this encounter and explain it through the enemy NPC patterns that we have created. The designers used Shield NPCs in order to bar the player’s way from one direction and give the illusion of a higher degree of challenge. However, by adding in the Grunt NPCs it allowed them to encourage the player to move into an advantageous position. The interplay between these two types helped to create an encounter with a low amount of challenge but high amount of tension. WEAPONS IN FIRST-PERSON SHOOTER GAMES *Note: The work presented in this section is based on material originally developed in collaboration with Rob Giusti. To define and discuss weapons, game and level designers have re-purposed an existing classification system: the terminology used to refer to real-life weapons, terms such as “Sub-machine Gun” and “Sniper Rifle.” Though these classifications do easily explain the mechanics of the weapon, the use of such terminology fails to accurately describe gameplay behaviors and to encompass the fictional aspects of digital games. Knowing how a particular weapon functions in real life does not actually give an accurate depiction of how the weapon functions within a game. For example, the shotgun in Halo has a much shorter effective range than its real-life counterpart. Many similar weapons fall into different weapon patterns depending on how designers implement them. Though many action and adventure games use weapons, shooter games are affected by this lack of terminology more than others due to the fact that weapons are at the core of gameplay. In the vast majority of first-person shooters, the player's weapon never even leaves their view. In addition, weapons are the central method through which players interact with the world in these games. With this pattern collection we hope to create a language that can be used to describe weapons in a way that encapsulates the gameplay behaviors that each pattern elicits. Each pattern is named in a way that aims to be inclusive of all weapons, fictional or nonfictional, that elicits similar player behavior. We accumulated these patterns through analyzing weapons in popular and historically significant first- and third-person shooter games. ASPECTS OF WEAPON PATTERNS To provide a basis for defining patterns in weapon design, the following template will be used: Name – A descriptive identifier used to refer to the pattern that is recognizable and imparts the core functionality of the pattern. Description – A brief explanation of the typical features of a weapon derived from this pattern. Affordances – Aspects of the pattern that can be varied between different weapons within the pattern. Consequences – How use of the weapon pattern affects gameplay. Level Patterns – Relationships between the weapon pattern and patterns in level design. NPC's – Relationships between the weapon pattern and patterns in non-player character design. Examples – Uses of the weapon design pattern from popular commercial shooter games. Patterns contained within another are considered to be super- or sub-patterns of each other. Patterns are not mutually exclusive from each other; a weapon can fit multiple weapon patterns. A large number of affordances can be considered universal among weapon patterns, including: How much damage the weapon deals The range of the weapon The area of effect of the weapon How often the weapon can be used ("Cooldown") How many times the weapon can be used before needing to be reloaded (“Capacity”) How much ammunition a player can carry How carrying the weapon affects the player’s movement How the weapon imparts damage to the enemy (On hit, delayed, continuous, etc.) Any special effects that the weapon has on the enemy Any special abilities that the weapon bestows Repetition of a Universal Affordance within a particular pattern description signifies that pattern differs significantly within the pattern in that aspect. PATTERN COLLECTION PROJECTILE Description: Objects thrown or fired in a physics-defined arch. Most often, Projectiles are explosives that deal damage in a large area of effect. Projectiles are also associated with long reload times and small capacities. Projectiles also often have a low amount of maximum ammunition. Affordances: The range of the weapon If the effect is immediate or delayed The area of effect of the weapon Any special effects of the weapon Consequences: Projectile weapons are useful for circumventing cover. Also, they heighten the challenge through being more difficult to aim than other weapons. Level Patterns: Projectiles can be used to harm enemies in Sniper Locations or guarding Choke Points without directly engaging them. Players using Projectiles are often vulnerable to Split Levels and Galleries, due to ammunition limitations and a lack of sufficient cover. NPCs: Grenadiers, Elites, and sometimes Tanks use Projectiles to force the player out of cover and impose a greater threat. Projectiles allow players to take on large groups of enemies, such as Swarms and Carriers, and fight against heavy enemies, such as Tanks and Snipers, without engaging them directly. The long recharge times and tendency for Projectiles to have large areas of effect make them less effective against Berserkers and Suicidals. Examples: The Demoman class from Team Fortress 2 [54] has a Grenade Launcher that allows the player to fire pipe bombs at enemies. These pipe bombs explode on impact with an enemy; otherwise the bombs roll for a few seconds before exploding. In the Halo series, the rocket launcher is a weapon that is both a Launched Projectile and Power Weapon. The weapon launches a rocket at high velocity, creating a large explosion that can instantly kill targets, both those on foot and those in vehicles. However, the weapon carries very limited ammunition and takes up space in the player’s limited arsenal. A player firing Projectiles in Team Fortress 2 Thrown Projectile Description: A non-bullet object thrown by the hand of the player's character and categorized by short range and highly affected by gravity. Thrown Projectiles often have high damage or severe special effects, balanced by scarce ammunition. Affordances: Special effects associated with the physical object of the projectile Consequences: The player is able to attack opponents who are behind cover, however they are forced to keep in mind their ammunition and range limitations. Level Patterns: Thrown Projectiles allow players to defeat an enemy guarding a Choke Point, or players on another level of a Split Level. In areas with long distances, such as Sniper Positions, or with enemies at multiple angles, such as Arenas and Flanking Routes, Thrown Projectiles are not very effective. NPCs: Elites utilize Thrown Projectiles in order to pressure players who are taking cover. Some Summoners use their spawned units as a sort of Thrown Projectile as a way of deploying them. A player can use Thrown Projectiles much like normal Projectiles to attack heavy Tanks from behind cover. Thrown Projectiles are often more effective against solitary, close-range targets and less effective against loosely grouped Swarm and Grunt enemies. Examples: In Call of Duty 4: Modern Warfare 2 [52], the throwing knife is a powerful Thrown Projectile with harsh limitations. The weapon has a short range, however a hit with the knife immediately kills the enemy. A player also may only carry one knife at a time. Halo 3 offers players a handful of varied thrown projectiles. Fragmentation grenades can be thrown a good distance and rebound off any obstacles until they detonate after a set amount of time. Players also have the option of using plasma grenades instead, which attach themselves to level geometry and players on contact, but have a shorter range and smaller blast radius EFFECTS OF WEAPON PATTERNS ON LEVEL DESIGN By forcing the player to use particular weapons in certain parts of a level, the level designer utilizes the relationships between the weapon and level to best control the experience and gameplay. For example, in the Ravenholm section of Half-Life 2, the player begins the level with a weak Melee Weapon, Sidearm, and Assault Weapon. The player progresses through Arenas and Chokepoints with a numerous number of Grunt and Swarm enemies, resulting in high tension and challenge. Later, the player fights Berserker and Carrier enemies, but acquires a Close Blast weapon and moves into Choke Points where the player has the advantage. The tension and challenge drop to give the player a respite and allow them to learn how to utilize the weapon. As the player proceeds, the level patterns become more Arenas and Split Levels, forcing the player to use weapons accordingly, bringing the challenge and tension back up for the climax of the level. In multiplayer levels, weapon placement allows the level designer to direct players. The designer can hint at what weapons are best suited for a certain area, force players to carry an unsuitable weapon across an area to get somewhere where that weapon is more useful, or even make it more difficult to use a particular weapon from a particular location. The multiplayer level Blood Gulch in Halo has Sniping Weapons atop each base at the ends of the map, overlooking large amount of the level and subtly hinting at the advantageous Sniper Position. A Power Weapon, the rocket launcher, is placed in the center of the map, forcing players to travel a long distance and expose themselves in order to procure the weapon. The multiplayer level Blood Gulch in Halo APPENDIX A - ADDITIONAL DESIGN PATTERN COLLECTIONS MULTIPLAYER FIRST-PERSON SHOOTER LEVELS *Note: The work presented in this section is based on material originally developed in collaboration with Chris Ueda. In our examination of multiplayer levels, we will be paying particular attention to their relationship to single-player levels and their associated patterns. Certain elements of multiplayer design patterns have parallels to their single-player counterparts. While these parallels suggest a large overlap in design principles for the design of levels in a (FPS) game, there is a difference in design goals between single and multiplayer levels. The goal of the level designer is to provide a specific gameplay experience to the player. Experiences such as a distinct gameplay experience or narrative diegetic effect can be produced by designers through the use of level geometry, item placement, scripted events, and other level design elements. A single-player level is designed as a linear space, segmented into rooms separated by corridors. This allows the designer to create highs and lows in player tension, pacing the gameplay and giving the player opportunities to experience moments of intensity without tiring themselves out. For example, Half-Life 2, a single-player FPS, often makes extensive use of open spaces in which the player is guided through the level while being given visual cues tying narrative and world space together. The level tells the story rather than large blocks of text or cutscenes, adding to a sense of immersion. The difference in player count between single-player and multiplayer affects the way in which the designer needs to approach level design. When crafting a single-player level, the designer aims to tailor an experience to one player, but in designing multiplayer levels, the game state is now based on the inputs of other players, whose game-playing experiences the designer must all consider. An example of the differences between single-player and multiplayer levels is apparent in spawning points for players versus spawning points for NPCs (non-player character). While they have similar purposes (introducing new entities into the level), in multiplayer levels additional players are spawned in place of NPCs. In a singleplayer level a NPC can be created whenever the designer chooses, but in a multiplayer level, the designer must equally consider all players when designing spawning points in a level. As the spawn points of each player affects the encounter rate, and therefore the pacing of the game. If too high, a player may get exhausted by constant action, or get bored between respawns if it's too low. Level design patterns are employed by designers to explore design choices and craft the desired gameplay for a level. These patterns vary based on the requirements of the game. For example, FPS gameplay involves the use of space and resources in real-time in a way that makes cover or item pickups useful. Therefore, patterns emerge that relate to the placement and frequency of these objects, and these patterns differ according to the unique features that distinguish multiplayer from single-player gameplay. KEY CONCEPTS CONFLICT POINTS A conflict point is a location in a level which is designed to bring opposing forces into an encounter. These locations are key in managing rhythm and flow in multiplayer levels. By designing a level with conflict points in mind, the intensity and pacing that a given player experiences can be adjusted. To do this, designers can utilize elements of a conflict point such as chokepoints, strongholds, pickups, and objectives. Chokepoints and strongholds change the movement of players in and about a conflict point, while pickups and objectives provide players a focal point for encounters. A powerful weapon or a bunker may motivate players to prioritize combat in that area, increasing the overall intensity of the location over others. Examples include the flag's location in a CTF game of Halo: Combat Evolved, Control Points in Team Fortress 2, or the Farsight XR-20 (an extremely powerful weapon) in Perfect Dark. These are objectives that players can obtain to get an advantage, and naturally conflict will occur in their vicinity. Use of conflict points is critical to many design patterns, as multiplayer FPS levels depend on them for creating player encounters. For example, bomb sites in CounterStrike serve as the objective destination for the Terrorist forces. The objective of the Counter-Terrorist forces is to prevent the Terrorist demolition mission, and both teams are aware of the state of the bomb sites through in-game HUD cues. These areas are often camped, with one team lying in wait to ambush the other team. The expected combat in the conflict point reinforces player planning and coordination followed by a burst of high-intensity combat. To support this style of gameplay, these bomb sites often contain various types of cover and are connected to the rest of the level via small, easily ambushed entryways serving as chokepoints. PATTERNS IN MULTIPLAYER GAME TYPES Multiplayer FPS games require a different set of game rules and objectives from single-player. Sets of rules collectively known as game types are defined in order to provide specific gameplay experiences. These may include rules such as a priority object or location, or a score objective. Level designers apply key concepts of multiplayer level design in the context of a specific game type in order to create a playable level. CAPTURE THE FLAG (CTF) This game type has both teams simultaneously on offense and defense, trying to claim the other team's flag and bringing it back to their own base while protecting their own flag. The game type is similar to Control Point, especially when the flag is located at a team's base. The flag's starting location serves as a point of conflict, and is often a strongly fortified location, making defense easy and requiring coordinated offense to capture. After claiming the flag, a player must bring the flag to their team's own base. The enemy team must prevent the flag from being delivered by attacking the carrier. Flag carriers are encouraged to use alternate paths and shortcuts in order to evade the opposing team. Levels are often symmetric to ensure balance. Respawn times are long, allowing a team to press their advantage after defeating opposing forces. Examples include Unreal Tournament - Facing Worlds (symmetrical) and CTF4 in Quake 3 Arena. Blood Gulch in Halo: CE is a classic example, set in a wide, open canyon with rolling hills. On the two far ends, a single bunker houses each team's flag. Teleporters quickly move players from a base to the middle of the stage, but not the other way, allowing respawned players to return to the action. Team Fortress 2's Payload maps are a variation of the CTF format. In this game type the offensive team moves a cart forward by standing besides it, while the defense sets up fortifications to prevent progress. The linear path of the cart and the respawn system of TF2 distinguishes this game type as being closer to CTF rather than Delivery, described further below. Team Fortress 2's Goldrush, a Payload map where the blue team moves the cart along to its destination PATTERNS IN MULTIPLAYER LEVELS Multiplayer level design strives to create a level playing field. To provide gameplay options while maintaining this balance, beneficial structures such as sniper locations and alternate routes need to be viable, while the opposing players are provided with a valid counterstrategy. In Halo: Combat Evolved single-player, a sniper location provided a significant advantage to the player. In the multiplayer game, players in sniper locations must also be wary of counter attack from the complementary sniper location on the other side of the level, or rely on their teammates to protect a poorly defensible position. Team strategy may be required to make the most of a given pattern's potential, often reflected in a strong offensive or defensive feature of a location. ARENA Description: Open areas with good sight ranges. Promotes encounters as a result of visibility or traffic – arenas are often conflict points Affordances: Can contain a Control Point. Pickups will increase traffic and conflict in the area. Can include features such as battlements and alternate paths to prevent overcongestion. Consequences: If surrounding area is confusing or congested, adding arena features may improve traffic flow. Has sporadic cover, providing good defense but not concealment. Examples: de_aztec (Counter-strike) - The terrorist force cross an open, unprotected area and take cover behind the crates located at demolition point A. A ramp up from a lower floor and a hallway with clear view of the bomb point threaten the terrorist force's objective. Hang em' High (Halo: Combat Evolved) - An extremely open map, with small blocks for cover, and ramps leading up to a second level which surrounds the map. Catwalks crisscrossing the level can be accessed from the second level. These lead to powerful weapons, but players are vulnerable to attacks from below. Halo: Combat Evolved, Hang em' High: Many catwalks cross the length of the map Follow this link for the full writing: https://users.soe.ucsc.edu/~ejw/dissertations/Ken-Hullett-dissertation.pdf Follow Ken Linkedin: https://ca.linkedin.com/in/khullett Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  5. For years I’ve been taking a pretty standardized approach to designing each new map in Cogmind, and although we have dozens of them now, it’s one of the few topics I’ve never covered on the blog. This is essentially because a serious in-depth look at the entire process would require spoiling a lot of content, considering that all the most interesting maps have been located beyond the early game. But with the recent release of Beta 8, which adds a very interesting map right to the early game, we now have a good opportunity to discuss map design without worrying too much about spoilers, since for the most part it’s easily accessible content anyway. This article will walk through every stage of the design and implementation process, from start to finish. I took a lot of notes about the process itself as I was building Beta 8, specifically so I could share them here and to ensure that what I write is an accurate representation of what actually went down. Note that unlike the majority of maps in Cogmind, due to its nature this particular map has a mostly static layout and content rather than drawing heavily on procedural methods. As such the process is missing a few steps, but I’ll cover those separately in an addendum. A mostly static map, on the other hand, provides some unique discussion opportunities of its own. Conception Before even starting, each map idea needs one or more concepts to build around, and in this case we have several goals: add more potential variety, especially to the early game provide more early plot hooks help new players For a very long time my notes for potential Cogmind features contained the concept of “derelict labs,” a way to access strange and fun technology, so when I started feeling we’d need a new area of the game to achieve all those goals, this concept seemed particularly fitting. Once I’d decided this was likely to happen (several months before actually doing it), I began intermittently revisiting that section of my notes to expand it with new ideas and considerations. On each new visit to add more ideas, I’d intentionally avoid rereading previous notes on that topic, instead just appending any new thoughts at the bottom. This keeps me in the unique frame of mind I’m in at the time, allowing me to come up with potentially very different ideas, or even perhaps the exact same ideas again without realizing it 😛 (this because usually days or even weeks have passed and I’ve forgotten the details of my earlier ideas). Note that coincidentally repeating notes on the same ideas can actually be valuable, because it validates them, perhaps with different reasoning, or even fleshes them out in different directions I hadn’t thought of in previous note-taking sessions! This process resulted in a total of about 2,600 words of rough notes on the topic, which like all of my notes are organized as nested lists in a TXT file. The entirety of rough notes on the new map, as seen in my editor Normally I just delete rough notes once their contents have been implemented or converted to more permanent notes elsewhere, but this time I saved them to share with you. Download/read the original notes here (you’ll need line wrapping off to view them properly!). Since the notes are a top-to-bottom process, you can see how they kept getting longer and longer with each extension as I apparently went back and forth on various points. There’s even “final summary” followed by the typical “final final notes” followed by “no wait, final final reverses that” xD In short, a new mini-faction of “Exiles” from another community has their own lab, offering the player both a new sensor ability (dubbed “FarCom”) and access to prototype gear from among a pool of possible items. Story-wise, they become the player’s earliest significant exposure to the world’s lore. As such, it’s good that I’ve circled back around to add this map after the rest of the world is already completed, so they can hook into it properly based on my knowledge of how everything can play out both in terms of story and gameplay. The alternative, trying to build this map from the start, would’ve likely meant repeatedly updating or changing its contents as the rest of the world was built. (Cogmind’s world was almost entirely built from beginning to end, rather than skipping around.) I’m not a fan of ripping out or making significant changes to old content, preferring to get it right the first time. So back in late October when it came time to add the Exiles, the first task was to reorganize those rough notes. This normally means reading back over them to remove the stupid ideas, refine rough ideas, and generally consolidate the notes while expanding on any unclear points, making sure it all fits together in support of my vision for the map. I didn’t spend very long in this phase, though, because there were simply too many notes this time around, and more importantly they were just going to be converted to a new form shortly afterward anyway. After just deleting some unnecessary chunks and making a few modifications, I quickly started on the proper map design doc. Map Design Doc The last planning stage before actually working on a map is to finalize all its relevant notes into a basic format I’ve been using since the beginning of Cogmind Alpha. Each map generally has its own text file describing its design. I call these text files “supplements,” since the idea originated when I started using these external files to supplement Cogmind’s original design doc, a massive file which started to get a little unwieldy by the time the first public Alpha was released after two years (plus I didn’t like the format/program that was used to create the original doc and wanted to start moving away from that, and by then the entire primary design doc had been implemented anyway). Supplements for various maps added over the years. “EXI” is the code for Exiles--note its size relative to the others. It happens to be one of the more complex maps, with a lot of possible content and various scenarios. Map design docs break down their contents into a number of common sections, including at the very least the following: goal: Main purpose(s) behind adding the map to begin with layout: An overview of environmental factors including the terrain and any props the player will see inhabitants: Descriptions of all the entities (in Cogmind’s case, essentially robots) found on that map gameplay: Primary interactive elements of the map, including any cause and effect related to dynamic content These are the main four, but some maps have one or two additional note categories applicable to that map in particular. For example the Exiles design doc adds a “location” section, because unlike most maps there are a number of important comments to make regarding how to access this map in the first place, and its general position in the world. There’s also a large “part concepts” section for collecting ideas for their stash of prototypes. You can read the entirety of the Exiles map design doc here (again, turn off line wrapping). If you checked out the rough notes earlier, you can see how they evolved into the proper design doc, which weighs in at three times the size (about 7,500 words). Some of the minor details in this doc may not be the same in the final implementation since I sometimes make last-minute changes that aren’t necessarily reflected back in the notes, but it’s mostly accurate. High-level Design It’s extremely important to expand the initial map design process to include considerations beyond the map itself. How that map fits into the bigger picture with regard to overall player strategy should be determined in advance, since it can have a broad impact on a map’s content, and if not careful a poorly planned map could end up needing more significant changes later on if players find that it’s either not very interesting or useful to them in the long run.* (*There is currently one optional map in Cogmind which unfortunately fits this description: Recycling. It’s a relatively simple, small map with some unique mechanics of its own, but its advantages aren’t really as enticing for players as I had first envisioned them when it was created early in Cogmind Alpha. Back then I was just getting started adding optional maps, and have learned a lot since then, including by way of the player community as it’s matured. I have plans to improve it one day, but it’s not a pre-1.0 priority since it’s rather out of the way anyway.) I wouldn’t want to waste player time, or my own, so the Exiles map in particular has a number of long-term strategic implications, and properly building them into the experience as a whole involved addressing different kinds of player needs, goals, and… um, craftiness 😉 Like pretty much all of the many optional branch maps in Cogmind’s world, the Exiles offer tradeoffs, making certain areas easier while increasing the challenge level in others. Primary long-term strategic decisions related to the Exiles. Note that some “drawbacks” may even be seen as good (or at least neutral) by certain players, so there are alternative interpretations to this graph as far as coloring goes. (I’ve chosen the most common view.) There are other random Exiles scenarios which can affect the available options, but I’m covering just the most common one here. Also, graphed above are only the major strategic considerations--individual prototypes can change a player’s potential route or even suggest builds depending on what they are, because they’re selected randomly from a pool of possibilities. Overall this one map has really opened up a lot of new options! I’ll talk about these options in more detail later. As designed, the standard Exiles benefits (one free prototype + FarCom) are especially noticeable in the short-term, at the expense of long-term drawbacks, making them a great choice for new or inexperienced players. That’s not to say they can’t be useful for experienced players as well--already one player won an extended run despite using FarCom, which essentially makes late-game Research branches off limits, even though that’s where one normally accesses a lot of the most effective tools for tackling extended game challenges. Having tradeoffs makes visiting the Exiles much more interesting, and they’re essential, too, because without tradeoffs it would be easy for a player to become overpowered, and a no-brainer to route a run through this map. Naturally not every map needs such explicit drawbacks, since in a lot of cases the drawback is the inherent cost of reaching and/or fighting whatever is in the given map, but here I should emphasized that the inhabitants of this particular map are all friendly, and reaching it is quite easy, so stronger measures were required. Okay, planning is over, time to start doing. Building Blocks As we already have our high-level analysis and relatively complete plans to guide construction of the new map, the first stage is to put together its entities and items, basically any individual objects that can be created in isolation. This would be the “pieces before the puzzle” approach, breaking down a large project into its smallest parts and working on each of the latter first. But I’m not even adding them to the new map at this point--it doesn’t even exist yet. Since there’s a lot of work to do for such a giant chunk of content, trying to add each new element to the map as it’s finished would often involve thinking at multiple levels (local area, map-wide, game-wide…), which is a lot less efficient than focusing on as few aspects as possible without constantly bouncing around. Working efficiently is not only faster, but also gives better results. So the plan here is to get all the pieces in order, then put them together all at once. Personally I like to start with the pieces that require the most time to implement, which for me includes most importantly anything that I think would be fun and interesting but is ultimately “optional” when it comes down to it, such as certain rare special events, items, etc. Stuff like Beta 8′s time travel-enabling “Chronowheel” item took forever, one of those things where I’d say “okay I’m going to tackle this one today,” then at the end of the day it’s “okay, I’ll just have to finish this tomorrow…,” and then a couple days later I’m like “uh, really gotta finish this thing up today!” (and maybe still don’t xD) But this is the type of content that really makes the project feel more like what it really is, a world built out of passion rather than just a “good enough game to sell and keep the lights on.” If I leave this tough optional stuff until later in the release cycle, it’s more and more likely to get dropped as I see the deadline approaching and there’s still so many other necessary tasks left to do, not to mention the fatigue of what it took to get near the end of the release cycle in the first place. In the end I’m always glad I’ve done these parts of the content, but I have to essentially force it through proper planning to make sure it actually happens 😛 Items Items are the smallest building blocks of a map, so we start there. The notes and design doc originally listed them in completely random order, but again in the interest of efficiency I somewhat reorganized the list to keep certain categories together. For example all projectile weapons should be worked on in succession, since they would all involve similar parts of the data and code. This makes working down the list flow more naturally, without having to jump between too many different areas throughout the source/data, mentally loading extra scopes. Before starting on any code or data at all, however, I worked with a completely different scope: art. All the art for the new items (more than 30 of them) was done together over a several day period, since again it makes sense to tackle like tasks in bulk. It can be harder to bear when a process like this stretches on for weeks or more, but as a solo dev who can only do one thing at a time, despite game development being a huge long-term undertaking, the efficiency gains are pretty vital. Art for some EX-tech prototypes found in Beta 8. Each of the new primary NPCs I’d planned for the new map have “signed” their prototypes with their name. Immediately after the art came the lore. Each of the new items has some lore text associated with it, and seeing how that would in some cases help define or refine the item capabilities themselves, I wanted to make sure they were all accurate and consistent. So all of those entries were written at once, also important here since because they’re generally meant for the player to discover/read them in a particular order. And finally it was time to create the dozens of items themselves--adding the data, balancing their stats, etc., which altogether took a couple weeks. Some items can be added in as little as 30 minutes or so, while others like the Chronowheel mentioned earlier could take several days. The “Latent Energy Streamer” weapon adds a whole new resource in the form of “latent energy” which could potentially be more widely used later, but for now the entire thing was added specifically for just that one weapon, despite taking several days to complete xD Latent energy is found throughout the environment, more often concentrated around stationary props like machines and doors. Activating the LES, which also reveals latent energy nearby. The LES draws on that energy and focuses it for devastating amounts of electromagnetic damage over an area, but also has side effects such as destabilizing nearby explosive machines, breaking automatic doors, and even corrupting the user. In fact, a number of the Exiles prototypes have negative side effects, which is what makes it possible to give the player such powerful parts early on in the game. Firing the LES. The firing animation took a while to perfect, too, being different from normal weapons in that it more closely ties into the surrounding environment, tracing lines through the latent energy that it’s actually using to fire. The LES itself also has a unique tag which displays the amount of nearby accessible energy in number terms, as well as shows the actual range of damage it can convert that energy to, values which change as the local energy naturally ebbs and flows, or is used up and slowly rebuilds. I’m really glad the LES is in game (and can’t wait to get a chance to use it myself during a regular run :D), though if I’d waited until late in the dev cycle to add it I’m not sure it would be a thing. NPCs After items comes another basic building block: NPCs. Some of these bots make use of the new items so they couldn’t come first, but once the items are ready we’ve got everything we need to put bots together, and an entity (robot) is a pretty self-contained little unit of development that doesn’t rely on the map itself (but will become a part of it), so they’re a good candidate for getting out of the way early. They take a while to build and balance, but focusing on them individually now means it will be easy to drop them all in on short notice when and where we need them later. The Exiles map includes four new core NPCs, each of which has a line of data defining their properties. It’s a fairly long line! As a demonstration, here’s the data for one of the new NPCs, 8R-AWN. (I’ve wrapped the line a couple times here so as not to force quite that much horizontal scrolling :P) When their data is complete, I run them through a separate program that can analyze robot designs and tell whether they’ll be overweight, have resource problems, overheat in combat, or any number of other issues. Their stats can be adjusted as necessary before moving on to the actual map 😛 Actually no… At this point I also decided that before the map itself I’d implement the FarCom sensor ability they can give you. This, too, could be worked on as an isolated system since I could test it explicitly rather than immediately developing the proper method of obtaining it in game. It could be hooked in as a piece of the puzzle later. FarCom in action, showing a faint circle within which hostile 0b10 combat bots are detected. (The circle has a slow pulse to it, but the gif doesn’t capture that well.) From an overall design perspective, there are enough types of differences between FarCom and normal attachable Sensors that there is no clearly superior form of detection in all scenarios. Each has their own benefits and drawbacks. A comparison of standard Sensors vs. FarCom. Green cells are a positive, red are negative. That said, FarCom is definitely a clear boon for new players, who get a free way to locate threats from afar without relying on any items for that knowledge. New players don’t have an easy time finding (and knowing to use!) Sensors, and parts can be destroyed, while FarCom cannot. The unquestionably most significant benefit from FarCom, one that’s quite attractive even to non-beginners, is that it doesn’t occupy any part slots at all. This is especially true in the early game where two slots is a larger relative portion of Cogmind’s available slots. Sensor users can try to get away with one slot (just the array without an interpreter), but getting the same level of detail that FarCom offers requires two slots devoted to sensor data. Freeing up a slot or two means extra armor, more storage, better targeting, and/or any number of other utility options, and this is a benefit that extends throughout much of the run, wherever FarCom is active. Of course, using FarCom is still not something everyone will always want to do, as per the earlier chart showing the serious late-game drawbacks. Overall I’m pretty happy with how it’s turned out. Layout and Integration Time to build a map! Sort of 🙂 I always start on blank sheets of loose paper since I find it the most natural, fast, and free-form. Exiles map general layout, content, and world connection planning. Most of that page is actually occupied by graphs considering how to connect this new map to the rest of the world. The route the player has to take to reach a map, and return to other areas, are important factors in setting the related rewards and challenge level. The Exiles are accessible from either -10 (essentially the lowest/earliest depth!) or -9, by the way of the Mines at that depth. They will only appear at one depth, though, and as the entrance is somewhat tucked away inside the Mines, I added a special indicator that lets observant players know when they’re at the same depth as the Exiles. I didn’t want players potentially wasting their time scouring an entire Mines depth for an entrance that might not even be there, so I drew on so-called “level feelings,” a mechanic found in a number of classic roguelikes such as NetHack, ADOM, and Angband whereby on entering a new map you get a log message reflecting a special aspect of that map. Cogmind’s first application of “level feeling,” added to save players time when searching for the Exiles. Players can also read lore in the Exiles Terminals which explains the scanning. As for the return trip after visiting the Exiles, I had thought to maybe send the player back to the main path through the Lower Caves, but that was when I was initially trying to restrict the design to existing options. Instead I ended up deciding to add a new Mines depth at -8, one that can only be reached while returning from the Exiles. This is both better gameplay (Mines are the smallest and easiest maps, suitable for weaker players) and more logical (the Exiles shouldn’t feel quite that close to the Complex, hence no immediate return to it from their map). In-game world map showing a player route having visited the Exiles and come back to -8/Materials through -8/Mines. That Mines depth is not normally directly accessible in the reverse direction, from -8/Materials, to avoid adding unnecessary exits in that map. The little nondescript blob at the top right of the note paper is actually quite important, determining the general locations of entrances/exits for the map itself, which in turn can affect the whole map design (terrain layout, content positioning, event timings…). These most vital points determine the flow of the experience. The player enters from the lower-right, and almost immediately there’s a junction leading to an exit out (mainly necessary to provide an avenue for other robots to enter the map from this side--more on that later), then the main content area would be in the middle, and further to the left is a second “back exit” from the map. Lastly, on the left* of the notes is a list of ideas for things I’d need to add to the actual map layout, which I’d sketch out next… *I’m left-handed and tend to orient my paper horizontally and fill pages of notes from right to left 😛 Confident in the connections, it was time to sketch the map layout in more detail! First pass on a reference sketch for Exiles map layout. As a static map with important NPC interactions, the layout really had to take into consideration the flow of a new player coming in and experiencing it for the first time--who will they see first and what will they say so that the order of everything makes sense? So after doing the quick tentative sketch above (based on the earlier general list), I had to take a break from this and jump ahead a bit to work on content for a day, specifically dialogue. True, the NPCs haven’t been placed yet, nor is there even a map to place them in, but by writing out the dialogue in advance I could make sure no single NPC was saying too much or otherwise needed to offload some lines onto another, which might affect the layout. (It did.) After the dialogue detour, I did another pass on the map sketch, creating this second more specific iteration to match it: Second pass on a reference sketch for Exiles map layout. The player enters from the bottom right, sees another corridor leading to an exit but no hostiles in view so it’s safe to continue exploring. Also there are some “rigged” power sources in the tunnel forward, a mechanic only made available via Exiles tech and therefore will be new to the player--anyone curious will want to check them and out and continue exploring, first meeting 8R-AWN in the corridor there for a friendly welcome/intro chat. Then they’ll move into the central area and spot the second main NPC, EX-HEX, who introduces a bit more of the lore and invites the player to seek out EX-BIN to help with a project. From there they can go anywhere, either learning more about the place from prototype tester NPCs in the south area, or head north to get the main benefits of the map, FarCom and the prototype(s). Either direction is fine for a first experience. Then they can leave by heading back to the east side, but are more likely to take the rear exit. At this point I went ahead and put together all the extra terminal lore and minor NPC dialogue as well, since there might be something in there which could affect the map layout as well (there wasn’t, but anyway having just finished the dialogue it was good to keep up the pace while still in “writing mode”--efficiency!). Then comes time to break out my next tool: REXPaint. I turn the reference sketch into a general layout in REXPaint, measuring out cell distances to make sure everything will fit just right--not too squished and not too open, and that the average player FOV from a given position will reveal the right amount of content. Exiles map taking shape in REXPaint. For now it’s just a single layer containing the general layout, entrance, and exits, still no objects or other details yet. It’s also lacking some layout details that might emerge/become necessary as objects are added. And with that file saved it’s ready to drop into the game! (This map happens to have a fully static layout, so it skips some steps here that many other maps might require. I’ll cover those in an addendum.) Content It’s now time to build the actual experience, starting… outside the map 😛 As a beginner-friendly map which is still kind of out of the way, I wanted there to be some ways to help funnel new players in that direction. So before working on the map itself, I again wanted to develop along the flow of the experience by beginning with how players are most likely to find it the first time. 8R-AWN, the brawn to the Exiles’ brains and the first NPC players meet on entering their lab/cave, is sometimes out running errands for them, and the player might meet him while on one of these errands. In one of the first Materials floors, whichever matches the Exiles depth, 8R-AWN can be found making his way across the floor towards an exit the Mines. The chance he’ll be around is higher for new players who’ve never met the Exiles before (unless they’re using a seed, since seeded content should be consistent, irrelevant of player history). On spotting the player, 8R-AWN invites them to follow, and proceeds to trash hostiles all along the route to the exit. (Or if the player is on the far side of the map, they may simply find a trail of destruction left in his wake from earlier, and 8R-AWN is long gone.) He’ll take the exit himself, and if he spoke with the player earlier will be waiting there when the player arrives before some more dialogue and continuing to lead on to the Exiles’ hidden entrance. Another possible encounter with 8R-AWN occurs during the Mines infestation. Assembled suddenly swarming into the area is a pretty deadly encounter for the unprepared, so it’s nice that 8R-AWN might show up to save the day, using special tech to shut them all down remotely. In this case if he spots the player he’ll also lead them back to the hidden entrance. This hidden entrance actually took a few attempts to design, since there needs to be a wall that opens up automatically for a friendly player, but I didn’t want the player to see a wall from a distance, conclude that it was a dead end, and never bother approaching, so the trigger was placed such that the walls would open immediately as they came into view. Exiles entrance layout design in Mines. To the player it will appear as if the corridor continues forward until they round the corner, at which point the hidden doors open automatically to reveal the exit as long as the player is friendly. This entrance is placed as a guaranteed prefab using the pre-mapgen method described here. Exiles That same post describes the data/scripting methods used to define the contents of Exiles, which as a static map is simply one giant prefab 🙂 At this point we can start dropping in all the objects that were created earlier--items, NPCs, dialogue, lore, etc. So it’s a relatively quick process since the objects are all ready, which is better than having to repeatedly stop what I’m doing to implement them. Instead I can focus on how everything is fitting together at the macro level, rather than worrying about low-level details. Once again we’re following the flow of the experience into the map from the right side, only this time using additional layers of the REXPaint to draw machines (gray lines) and mark entity and item positions (green letters and green numbers, respectively). Machines and other props, including invisible triggers, are identified using uppercase green letters. Final Exiles prefab in REXPaint with all data layers visible. The corresponding data goes into a text file, the features of which I’ve provided a breakdown before in “Map Prefabs, in Depth.” Complete Exiles prefab data in image form, since it’s easier to read with syntax highlighting enabled. (Some of the lines are really long but not worth extending the image for, so they’re just cut off.) The file is also available in text form. As I’m going through adding the objects, I make a list of all the related explicit tests that will be necessary to confirm the content is working as intended. I’m also constantly thinking of all the things that could go wrong and need to be looked into once everything is in motion. This list will be quite important later, and is better put together while each element is on my mind rather than trying to remember these points later, or coming up with tests from scratch. Despite my best efforts at the initial implementation, usually a number of things don’t work as intended, and it’s certainly better to work through it all systematically rather than wait for a stream of bug reports from players 😛 This is a fairly large map so I didn’t wait until everything was placed before testing, instead stopping a few times to test in batches, generally clearing out the list in the process. Bling With most of the main content done, I moved on to more superficial elements of the kind that can be tacked on. The FarCom mechanics were already implement much earlier, but it was still missing the animation played when you first receive the ability from the Exiles. There are a number of full-screen animations throughout Cogmind which occur when major abilities are conferred, so FarCom shouldn’t be an exception. EX-BIN using the FarCom Aligner to add you to their system. One element I also always leave for the end of the content phase is audio. Working with sound effects involves concentrating on tasks other than code, including managing a bunch of audio files and messing with them in Audacity. It’s more efficient to do all of them together, so whenever I come across something that needs audio I just leave a placeholder and add it to a list, one that gets taken care of after the rest of the content. Ambient audio visualization of the area around the FarCom Aligner, where brightness indicates volume. For those who want to read more on this, I’ve written about ambient sound before. There were other non-ambient sounds to handle as well. Variants I keep saying the Exiles map is “static,” but that doesn’t mean it can’t have a little variety! There’s the usual variety created via the prefab data shared above: Common items in store rooms are randomized, as are the prototypes (where there is quite a large amount of variety since the items can change up gameplay significantly, but appear in different combinations each run). There’s also some variety created via the fact that you may or may not meet 8R-AWN before reaching the Exiles, in different situations, so that makes for unique dialogue options. But the most significant variety comes from players not always finding the map in its default state at all. There are actually four different scenarios, the above text describing only the first. As part of the world generation, a random state for the map is chosen from among the following: 51%: The default scenario, as described. This state is also always forced under a number of other world conditions outside the map, so the effective percentage is somewhat higher. 12%: Deserted. The Exiles have already wiped their terminals and abandoned their lab. 12%: Destroyed. Complex 0b10 has already attacked the Exiles, leaving the place scarred from battle. There are no survivors to be found, but the area contains other useful remains. 25%: This is equivalent to the default scenario, except forces from 0b10 will attack while the player is there. I built the base map first, then implemented the 0b10 attack (essentially an event tacked on), then moved on to the other two variants last since they were less complicated. More complicated map variants should come first in case they require changing parts of the map concept itself to work right, whereas doing complicated variants later could mean having to waste time changing a bunch of earlier work! It’s hard to predict all the changes that might be necessary in advance, so prioritizing like this is important. The deserted and destroyed variants were easy to manage since they were basically just modified data and REXPaint maps. “Destroyed” Exiles prefab in REXPaint with all data layers visible. A comparison to the earlier default scenario reveals newly destroyed machinery, randomized (and randomly shifted) debris, exploded areas, and other different procedural content like possible salvageable robots. The attack scenario was the most time-consuming variant, since I had to watch the same battle again and again to see all the possible outcomes and whether they met expectations. I spent a couple hours just watching attacks, repeatedly tweaking various parameters to get the desired results. The Exiles are attacked by 0b10, with the map fully revealed for observation/debugging purposes. 8R-AWN covers the retreat, and EX-DEC drops a sentry turret before taking off. Special Considerations Finally almost done! The “normal” way to play is complete at this point, but there’s one more important stage: anti-cheese measures 🙂 Naturally some players will try to gain every possible advantage they can think of, even those requiring outright thievery or murdering allies, so it’s necessary to balance those possibilities, too. Aside: Not all roguelikes need to be balanced like this--some even revel in being totally unbalanced, but for the most part Cogmind is meant to be a tightly balanced experience. Even though some players do still manage to stretch the limits through extreme cunning, which is fine, I want to be careful about allowing specific actions to be so rewarding over others that players always see it as “the proper way” to do something, to the detriment of all other possibilities. Sure the Exiles are a friendly bunch, but players who see them as a means to an end will likely… try to end them. Handling this was a bit more complex than usual because the Exiles experience isn’t limited to a single map--player hostility could begin wherever they see 8R-AWN, thus behaviors could change during future meetings, including on the map itself. Earlier I charted the strategic decisions a player can make with regard to the Exiles, and the whole reason these are decisions to begin with is that each comes with an associated cost. Players can choose to… 1) Use the default approach, by taking a single prototype from the Exiles vault and using that and FarCom scanning support to just tackle the main areas of the Complex. This is the easiest option, good for new players. They’ll lose the chance to get imprinted in Zion (normally another good crutch for newer players but one that doesn’t appear until the mid-game), and they’d have to avoid the late-game Research branches which are very deadly for players with FarCom. Balance-wise, this is because those branches contain alien tech and many of the most powerful items in the game. FarCom makes many other maps easier, at the cost of not having access to these resources. 2) Take one prototype and FarCom, and enter the Research branches anyway. This is extremely difficult. Entering a Research branch with FarCom triggers “Maximum Security,” the strongest response from the Complex so far, which is essentially like an instantly triggered version of “High Security” with even more assaults (basically endless increasingly strong waves of hostiles entering the map). This mode was added to Cogmind specifically as a response to FarCom, but also made sense to trigger in a few other special scenarios, so I applied it to those as well. You can see in the rough design notes that the original anti-FarCom plan for Research branches was to dispatch Trackers, a new type of fast and deadly prototype bot. Later I decided that Maximum Security was a better solution there (mainly as an even stronger deterrent), but having already done all the preparations for adding Trackers, I decided to at least make them part of a revamped Intercept squad system. Intercept squads are another form of tradeoff in Cogmind, originally intended to be very challenging, but players had gotten so good at strategizing that they weren’t quite challenging enough anymore--now the good players have to think long and hard about whether they really want to risk Intercepts 😛 Ideally like the FarCom sensor mechanic and other building blocks, something as fundamental to the overarching design as MaxSec and new Intercepts should’ve been determined much earlier in the map design process, but I hadn’t yet come up with a good solution and needed to let it sit for a while, and couldn’t wait any longer to start Exiles work for Beta 8, so it had to be postponed and wasn’t even decided until close to this final stage. Some major changes are best left in waiting 🙂 3) Steal all three prototypes from the Exiles vault and add some challenge to the mid-game caves. For those who really want more than one prototype, this is possible albeit with a bit of a drawback. For one, FarCom will no longer work since by stealing all the prototypes you didn’t follow their instructions, although for some players this may be a positive since entering Research branches then becomes a possibility (as does imprinting, if they want to!). The prototypes are quite powerful, so there needs to be a clear cost associated with stealing them. For this scenario I added a new drawback: Master Thieves. Although they’re not too common, Cogmind already has thieves hiding in caves, so I made a special variant which is even more effective and specifically tracks a thieving player any time they’re traveling through caves. If you steal from the derelicts, they steal right back--it’s an “eye for an eye” sort of deal 🙂 (Thieves race up and try to rip a part off their target, then run away and eventually disappear forever once out of sight.) Beta 8 has been out for a little while and the current meta among the better players seems to be preferring this route more often than others. I’m not sure if it’ll be necessary, but if this route is always superior there are other tweaks to consider, such as allowing Master Thieves to rip parts out of the player’s inventory as well ;). That said, I don’t want to make this tradeoff as expensive as the FarCom-Research thing--it should be something that players are willing to face under certain circumstances. 4) Steal all three prototypes but just tackle the main areas of the Complex, avoiding the caves. While not the easiest option, this is still easier than a non-Exiles run. Stealing all the prototypes means losing FarCom, but using sensors instead and avoiding the caves means staying safe from thieves, and still being able to stealthily raid Research branches for the best parts. Avoiding the caves does means losing access to some potential mid-game benefits, but those are optional and there are helpful non-cave branches to consider anyway. 5) Kill the Exiles, specifically 8R-AWN to salvage his own excellent prototype loadout, and also steal all three prototypes. This is basically the strongest result for the player (assuming no need/desire for FarCom), though also the most dangerous option since 8R-AWN is pretty powerful and Cogmind is weak at the beginning. Players are already doing this, though, because of course they are 😛 I did add the possibility of a Hero of Zion attacking the player as a result of their hostilities, but didn’t make it guaranteed since that, too, could be gamed by players for more cheese potential. I’d rather it just happen in some cases as more of a lore-related surprise. As you can see there are quite a few special considerations when adding a new map! Gotta think of how players will react to each possibility, and whether they’ll think certain tradeoffs are worth it. In making these judgements it helps that I play a fair bit of my own, and that I’m also always reading about player experiences. The next pair of articles are addendums to this one, covering steps specific to procedural level design, and a comparison of static vs. procedural maps. Source:https://www.gridsagegames.com/blog/2019/02/level-design-shaping-cogmind-experience/ Source:https://www.gamasutra.com/blogs/JoshGe/20190313/338510/ Follow Josh Website:https://www.gridsagegames.com/blog/ Twitter:https://twitter.com/GridSageGames Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  6. Introduction The purpose of this document is to provide guidance and insight for designers who are creating or working on a multiplayer level. I will address such topics as Flow, Item Placement, Initial Design, Architecture, and Testing. Although Capture the Flag and other team games are rarely addressed specifically throughout this document, because they are typically for a minimum of four players (two teams of two), with a higher number more often being the case (e.g. 4 on 4, 6 on 6). That being said, many of these guidelines will apply to those types of games as well. (The major new issue in a cooperative/team game is how the new goals will affect gameplay. For example, if capturing the flag and returning to your base is more important than killing your opponents, then a speed power-up may become more important than a better weapon. For another example, consider a location in the map that might be very difficult to hold in free-for-all play, but would become very easy to control for two teammates.) There are many accepted design principles that apply to level design in general. These will not be discussed in depth in this document, and include such things as: Attention to detail. Use of a consistent theme. Effective use of sound and lighting to convey an atmosphere. Sufficient time on either end of the design curve (i.e. planning and testing). However, there are many aspects of the multiplayer experience that can be handled incorrectly if approached from a single-player point of view. This will often result in the production of lower quality, unbalanced, poorly planned levels that will provide a disappointing multiplayer experience. For emphasis: You cannot reliably design good multiplayer levels from a single player point of view. Since overall level flow and item placement are two of the ways in which multiplayer level design differs most dramatically from single player level design, these two aspects will be mentioned first, then followed by more general design principles. Important: The following design guidelines in this document are general rules. As with all general rules, there are always exceptions and special cases. Sometimes good level designers can ignore some of these guidelines and produce excellent levels... but it's not the way to bet. Flow For purposes of this document, flow is defined as a combination of direction of movement, speed of movement, and pace of movement through a level. In a level with an extremely high degree of flow, a player will be able to move at a relatively consistent pace from any area of the level to another with a minimum of dramatic changes in direction and speed. In a level with poor flow, there will be starts and stops, awkward geometry to navigate, edges and corners to get stuck on, and many dead-end areas. Multiple entrances and exits Ideally, any major area in a level should have at least two (and preferably at least three) ways in or out (e.g. a room might have two hallways leading into it, a ledge above it that the player can drop from, and hole in the floor that a player can jump into to get to another area (three ways in, three ways out). To explore the idea of multiple entrances and exits, and the resulting effects on gameplay a bit further, imagine a room like the one below. "W" is a powerful weapon, and "H" is a health kit, and the room has exits/entrances on the north and east walls, and is somewhat flat and unremarkable: It's relatively simple in this particular example for a player to "camp" the weapon by standing in the corner and keeping a sharp eye on both doorways, attacking any player who tries to enter, and using the health kit to counterbalance any damage he or she might have received. Keep in mind that this "camper" does not have quite the same advantage that he would in a typical first person shooter (i.e. It's much more difficult to be sneaky in a game where the other player can easily look at your part of the split screen to see where you are), but it's still a tactic that can have a significant effect on gameplay. Consider the change below: Another door has been added on the west, the health has been moved to the NW corner, and the weapon has been moved to the south wall. Three doorways across a much wider field of view are more difficult to watch than two, and if the player still tries to camp the weapon, he or she has to move back and forth a bit more to obtain the health. This also leaves the camper open to attack by two or more other players from radically different directions (and it's much more difficult to watch what two or three people are doing on the split screen than it is to watch what one person is doing). For another approach, consider the following: The weapon has been moved to a spot between the two doorways where any player who moves through that corner of the room can quickly grab it, and the health is now by itself in the SW corner. Above the health is a shaft from the room above--impossible to travel up, but easy to see down and jump down. This produces some interesting gameplay possibilities and tactics. If a player is camping the weapon, he can be attacked easily through either doorway, and will find it difficult to watch both doorways at once. Suppose he decides to wait in the far corner, picking up health if he needs it, and ambush a player trying to get the weapon? It may work once or twice, but when his opponent catches on, the player will be attacked from a position of relative safety above, or his opponent will simply pay more attention to the player's position via the split screen. Relatively simple changes in room design and item placement can produce much more complex and flexible gaming situations. Note that teleporters, which instantly whisk a player from place to place, can serve to increase connectivity and flow within a level if the level geometry itself is uncooperative. However, teleporters are also easily abused by being used as a quick fix for substandard level design that shouldn't have seen the light of day in the first place. Clipping Geometry "Invisible boxes", "clip brushes", "see-through walls"--different terms for unseen geometry that aids the player in navigating through the level with minimal difficulty. Ideally, this aid should be of the subtle variety--anything that is too intrusive might distract the player from any immersion in the game world that has been created. For example, if there is a slightly protruding arch in a hallway that players tend to get caught on when moving down the hallway, the designer could place an invisible box along the length of the hallway on both sides with the inner plane of the box flush with the inner edge of the arch. What if the arch sides didn't protrude slightly, but instead stuck quite far into the hallway? A box that kept the player from getting anywhere near the wall would be an obvious and blatant "fix", but the designer could place a wedge-shaped brush on the near and far edges of both sides of the arch to gently force the player out and around the arch as they passed by. *Note: The use of clipping geometry will differ somewhat depending on whether the game in question is first person or third person. Something that might work well, and feel relatively unobtrusive from a first person point of view, might be very obvious and clumsy when experienced from a third-person perspective (and vice versa). This is just one area where a great deal of playtesting and feedback is essential. Dead ends In general, dead ends are a bad idea in any multiplayer level for a number of reasons: Dead ends promote poor flow. If a player has to stop or do a U-turn at the end of a dead end passage, then that area is somewhat awkward and clumsy. Dead ends are boring and/or frustrating. The player has to travel back through an area that he or she has just seen. Dead ends can easily result in "no-win" situations for a player. If he or she is trapped in a dead-end, there is no option for a tactical retreat. However, although the preceding points are generally true, in specific situations dead-ends can be useful (e.g. a powerful weapon or item can be placed in a dangerous dead-end in order to properly balance the value of the item with the risk involved in obtaining it). Summary: Have two (and preferably three) ways in and out. Think "outside the box". There are always multiple solutions to a level design problem. Use clipping geometry to aid flow and navigation. Use dead ends sparingly and for very specific reasons. Keep lines of sight in mind, and be aware that different camera views can produce unusual situations. Item Placement Poor item placement can turn an otherwise solid multiplayer level into an unbalanced and irritating gaming environment and can interfere dramatically with flow. Excellent item placement can add much-needed spice to an otherwise forgettable level, and accentuate the architecture and environment that has been created. The items in a multiplayer environment can be divided into four basic types: Offensive Items (e.g. weapons, ammo) There is generally a maximum amount of damage that a player is able to inflict in a given period of time in a given situation. Offensive items increase that amount. Defensive Items (e.g. health, armor) Defensive items increase the amount of damage that a player is able to endure, make that damage have less effect on the player, or allow the player to avoid those effects. Special/Other Items (e.g. binoculars, mine sweeper, jet pack) These are items that can somehow change the balance of the game in a way that isn't purely offensive or defensive (but could strengthen offense or defense for a player, depending on the player's particular situation). Team Items These are items that somehow affect game goals in cooperative play. The best-known example would be the flags in traditional two-team Capture the Flag. Flags are traditionally placed in two opposing bases that often have the same layout, geometry, and item placement (to more easily avoid giving one team a subtle advantage over the other). As a side note: As previously mentioned, this document does not focus on capture the flag (and similar games) to any great degree. However, one of the simplest ways to introduce a CTF-like element into a map for fewer players is to have some single power item or power spot on the map that a player gets points for holding or capturing. Item Quantity and Placement There is a fine balance to item quantity. There should be enough items to make it relatively easy to get the most basic necessities (e.g. basic weapons, some degree of health/protection), but not so many items that the challenge is eliminated and the player is stumbling over some new item every few steps. Generally, there should be fewer of the more powerful items in a level. There would be no reason to pick up the weaker items if there was a better item nearby. The more rare and powerful items can also be placed in locations that are more difficult and/or more dangerous to reach. There is nothing necessarily wrong with placing a powerful item in plain sight in the middle of the level where it is easily reachable by all the players. This placement in itself can add an element of danger as players wait nearby, simply watching the item, and attack other players as they approach. Just realize that much of the action will occur around that powerful item, and that there should be sufficient incentive for players to travel to other parts of the level. Powerful items can also be used to "balance" the level. In other words, if there is a powerful item or weapon at a certain location within a level, a good designer will be likely to put a similarly powerful item or weapon in another area of the level. This accomplishes three things: It makes it less effective to try to "camp" either item. It encourages players to move gameplay around the level. It makes it harder for a player to continually have both items and more easily control the game. Finally, some weapons can be placed in such a way that they are not only balanced to some extent, but also encourage more game flow and movement through a level. One simple example would be to place a sniper rifle in an enclosed area in the depths of a level--in order to make the best use of it, a player would have to get the item, and then travel up to the top of a high tower to get the best vantage point from which to snipe at other players. Ammunition and Minor Item Placement The placement of ammunition (if it exists in the game separately from the weapons), and the placement of minor items can be a much more subtle process then the placement of powerful items, and can be approached in different ways. Furthermore, many of the fine points will be very dependent on specific game mechanics. For example, a game with differing levels of health (or healing potion, or whatever generic "more life" item it happens to have) can have a much more complicated and "fine-tuned" item layout than a game with only one type of healing item. If a game has multiple weapon types and multiple ammo types (or even multiple ammo types for each weapon), this will result in more fine-tuning and more complicated decisions for the designer. A good general rule to remember is that if a player has everything he/she needs in one area, then there's little reason (gameplay-wise) to leave that area and explore the rest of the map. Item Setting It can add significant atmosphere and "feel" to a level if the items are placed in appropriate settings, and not just strewn about in relatively equidistant spots. One good (albeit subjective) rule of thumb: Every area of a level should be attractive enough for a player to want to visit it. Creating a proper item setting is a much more subjective process than some of the ideas that have been mentioned previously, as it deals with artistry and aesthetics rather than easily quantifiable factors such as damage and movement. Items, especially powerful items, are best placed like a gemstone placed in a ring. Impressive and/or detailed geometry, eye-catching lighting, or even props and other items can all be combined to create a memorable setting for items. Camping Revisited As was touched on above, it is very easy to create a situation in a multiplayer level wherein a powerful item (or even a not-so-powerful item) is placed in such a way that it is very easy to defend once it's obtained, and a player can "camp-out" at that location and dominate others who attack that position or try to get that item. For example, a machine-gun with a large supply of ammo and a health kit are placed at the end of a long corridor, behind a pillbox with a small "gunner slot" to shoot through. A player can stay there for a long time racking up victories with relative ease. While this example is an extreme one for illustrative purposes, it is easy to make this mistake in more subtle ways. This mistake becomes less likely if the designer uses the "at least two ways out" guideline, and incorporates some sort of vulnerability into every major item placement. Item Placement and Player Start Locations There seem to be two schools of thought on placement of player start locations relative to weapons and items, the first being: "Players should have to work to get good items/weapons. Gameplay becomes boring when players always have access to all the good items immediately upon starting a level." The opposing point of view goes something like: "When it's a difficult process to get good items and weapons, then the player who wins any particular skirmish always has the advantage, since he/she already has all the good stuff, and the defeated player has to restart, recollect items, and possibly fight off a beefed-up opponent while doing so." There is no clear answer or definitive formula to resolving this issue. Both points have some validity, and it will usually be safest to try to place your player spawn points while keeping both these points in mind. This is an issue that is usually resolved best with a great deal of playtesting. Ideally, player start locations should be placed with the following additional things in mind: Player starts should not be in a direct line of sight with each other. If they are, this potentially eliminates a major part of a good multiplayer game: maneuvering and responding based on where your opponent is (or where you think he is), and reacting to his movements with appropriate strategy or tactics. Player starts should be placed in places that are "off the beaten path" to some extent. It can put a player at an unfair disadvantage if he/she appears in the middle of a central combat area in the level, and can be frustrating if he/she is immediately defeated before gaining any real momentum. There should always be at least two nearby exits from any player start location. A player spawning into the game in a no-win situation (because a beefed-up opponent has them trapped in a dead end) is simply a result of poor level design. Secrets Finally, placing items in "secret" locations is generally a bad idea in multiplayer levels, since there will often be one or more players who don't know how to obtain the item (bad enough), but may be unaware that it even exists (worse). This sets up a dynamic wherein one player can easily dominate another player or players, only because of the "insider" knowledge that he or she possesses, and results in a blatantly unfair situation which can frustrate and anger players. (Note that I am not referring to items that are simply very difficult to obtain. If everyone knows where it is, it isn't a secret.) Again, although the preceding is generally true, there are some ways to make secrets work in a limited way in multiplayer games: The secret shouldn't be a "game-winner". A secret that gives someone an overwhelming advantage in a game = bad idea. A secret that helps a player slightly, or that simply gives some background color, or information of some kind about the game world = good idea. Secrets that are a relative "one-shot" (i.e. once the secret is discovered, pretty much all the players will know about it) are much less unbalancing. Secrets that have a random factor can work. These can be fun without being too unbalancing. For example, suppose there's a somewhat out-of-the-way spot where a powerful weapon will appear 5% of the time instead of the regular health that appears the rest of the time. Further suppose that there is no additional ammo for the weapon, and that there is no other weapon of this type in the level. This results in a player randomly finding this weapon on rare occasion and only using it for a very short time (thus being likely to establish no serious advantage). In a situation like this, "insider" information can be fun and can produce some interesting gameplay situations (as players begin to shadow the other player trying to find out where the "odd" weapon came from). Summary: • Balance item quantity carefully--enough items, but not too many. • Use powerful items sparingly and in a balanced way. • Spread minor items out, and avoid all-in-one locations. • Place items in a setting to be more aesthetically pleasing. • Make locations of powerful items dangerous or vulnerable. • Handle secrets with care to avoid unbalanced gameplay. Initial Design The initial design process can be a dramatically different one for different designers. Some individuals greatly enjoy it, because it allows them to visualize the level in broad strokes and come up with various ideas without necessarily needing to address some of the more "tedious" or "exacting" details that will appear near the end of the construction process. Other designers struggle to come up with a new and creative idea, or a broad outline, but excel in providing the fine points of a level's look and feel. Some level architects plan out their levels in exacting detail on grid paper beforehand, or work from detailed concept sketches, while others simply start from scratch, allowing ideas to evolve as they work. Both approaches have their pros and cons: A high level of preplanning assures that the designer won't wander off down the wrong track and possibly waste a great deal of time and energy, but can also stifle creativity and force a designer into "mental blinders" that reduce his or her potential. Summary: Everyone has their own way of working... but don't be afraid to think "outside the box" of your own habits, and possibly discover methods that will work better for you. Also, don't assume that work habits that were effective with one set of tools/one game/one design process will work well all the time. General Testing and Game Mechanics Testing is at least as important in multiplayer levels as it is in single player levels, and some would say that it's more important because the actions of a group of players are more unpredictable than the actions of a single player. While multiplayer levels are simpler in some ways than single player levels, players in a multiplayer setting can try new things (and find new problems) that might not have occurred if they were playing alone. Some design questions become exponentially more complicated when designing levels with a multiplayer focus. A few of the basic points to consider in testing and game mechanics: Testing Start Locations If you are one person testing a multiplayer level, it's easy to overlook non-functional or flawed start locations, especially if the start location is not always randomized, and if you do not have any sort of artificial opponents. Always make sure all start locations work consistently and correctly. Gameplay habits We all have a tendency to do things in a certain way, and repeat habits. The only way to be sure that the gameplay in a level isn't broken in some major way is to have the level playtested by someone (preferably many players) other than the designer. That being understood, you can at least playtest better as a designer by doing everything you can to break up your habits--if you find yourself always following a particular path in a level, then consciously go another way. Pretend that you haven't memorized every nook and cranny, and try to play like a new player: "Gee, I wonder what's over here..." Try to look at your map with new eyes, and you will often find problems or possibilities that you didn't realize were there. Gameplay mechanics Be aware that all games--even all multiplayer combat games--have different (sometimes radically different) gameplay mechanics. A couple of notable examples: Camera Angle Lines of sight are as important in multiplayer level design as they are in single player level design. Being able to see an enemy, or be seen by an enemy, is a key factor to victory. When playing from a third-person perspective (again, depending to some extent on camera movement) it's relatively easy to see where players are in relation to one another, and, if you are in a relatively high position, to potentially get a bird's-eye perspective on the entire field of play. In addition, when you are in a low position in a third-person game, it can be quite difficult to see what is above you when compared with a first-person game. When playing a first-person game, your field of view is limited horizontally to approximately 90 degrees, so losing track of your opponent can happen in the literal blink of an eye. In a first-person game, it's pretty much impossible to see anything that your in-game character wouldn't be able to see (i.e. you see through the character's eyes). In a third-person game, the circumstances involved in having a third-person camera view that doesn't necessarily change consistently with player movement can result in a variety of unusual possibilities at any given moment: If it's a console game, no players can see the others directly, but everyone still knows where all the players are by looking at split screens. No players can see the others directly, but players can shoot the other players (e.g. with a weapon like the grenade launcher or mortar that can shoot in an ascending-descending arc). Players can see each other directly, but players can't shoot each other. (This can happen if the players are positioned in such a way that the camera sees around a corner or over an obstacle for each player.) One player can see and shoot at another player without it being possible for the other player to see him directly, or hit him with return fire. (This could happen if, for instance, a player had a high vantage point, and was behind an obstacle of some sort. Direct fire from the other player would hit the obstacle, and arcing fire would either overshoot or collide with other geometry.) Line of sight issues are further complicated by the fact that any player might be able to kneel or drop prone at any time, which could change any of the above situations. It is also possible in some third-person games for a player to change the camera angle without actually moving (by rotating the camera in place). This makes it possible to stand facing in one direction, but keep a 360-degree watch. This would, of course, only provide an advantage in certain situations, and if you have the control skills to make it useful. Also, consider the effect of ground cover on combat. In a first-person game, the heavy use of ground cover (e.g. bushes, low walls, obstacles) can easily obscure the field of play and add a hide-and-sneak element, emphasizing the importance of accurate prediction of an opponent's tactics. In a third person game with any sort of height to the camera angle, this sort of ground cover is more of a simple obstruction to movement than a serious influence on tactics and strategy. These issues become very important to a level designer when questions about gameplay, balance, and tactics arise. Auto-Aiming For another example, consider the subject of auto-aiming. Auto-aiming (when the computer/game system does some of the work of aiming for the player), gives a very different feel to a skirmish, and a player must concentrate more on positioning, movement, and any other ways in which he or she can help the auto-aiming system along, and less on accurate crosshair positioning and shot-timing. Summary: Test extensively with real gameplay. Break up habits. Get another point of view. Alter your design to best utilize the specific gameplay mechanics and tactics that will be involved. Research To make good multiplayer levels, and to continue to grow in his or her skills, a designer needs to play lots of good multiplayer levels, and, unfortunately, the only way to play lots of good levels is to wade through even more levels that aren't so good. While you're playing a particular level, analyze what is working in that particular level--very simply, what makes that level good and not bad? If you don't know quite specific answers to that question, then you may not be able to create the same great gameplay and fun experience in your levels, and if you do, it may be by accident rather than by design. Finally, write things down. That may sound obvious and slightly juvenile, but you will not remember important things if you don't. I have a simple text file called "tips" that I just copy and paste tidbits of various kinds into--technical tips, design tips, interesting gaming anecdotes, "here's a great idea for a level" bits, obscure design facts, and so forth. If you have any doubt if you should put something in, go ahead and put it in, then review the file periodically and weed out things that are outdated, have lost their usefulness, or were just never quite as useful as you thought they might be. Summary: • Keep looking. • Keep learning. Source: http://www.robotrenegade.com/articles/multiplayer-level-design-guide.html *Note: This article is shared in full on Next Level Design in accordance with the Creative Commons Guidelines noted on the source site. Follow Patrick Website: http://www.pjwnex.us/ lvlworld: https://lvlworld.com/author/pjw Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp .galleria, .galleria-container { height:480px !important }
  7. This is the second part of a three part series of articles dealing with level design in action adventure games. Part 1 described Level Flow Diagrams, that act as the core of the level brief provided to a team by the Leads. Part 2 describes a process of expanding that brief into a detailed level plan. This stage of the process is most often carried out by a cross-discipline team of designers, artists and coders, who will expand the level brief into a detailed level plan, but this process can equally be the next step that an individual designer takes when designing a level solo. A Note on CollaborationDelegation and teamwork are vital given the scale of modern console development. Without them, leads become bottlenecks that slow development and sap motivation.The current trend is towards agile development whereby scrums are given ownership of individual problems. This has many advantages over the old waterfall methodology, but there is one pitfall to watch out for with peer-only teams.If a group of peers go into a room with the goal of making design decisions, the tendency won't be towards a design that everyone loves, but rather towards the design that everyone least hates.The psychology goes this way:1. Person X suggests a new idea that he thinks might be mint. It's not a complete idea yet, but he believes it has a kernel of goodness that could make for a unique piece of gameplay.2. Persons Y and Z who have not seen anything like this idea before quickly point out all the flaws in the idea.3. Person X, whose idea still needs nurturing, responds defensively, firing off hastily-thought out solutions that people also don't like.4. The idea is shut down and the group moves on. If person X brings it up again, people are going to think he is beating a dead horse.5. If person X brings it up again, people are going to think he is beating a dead horse.6. Next, Person Y suggests something that he has seen in a game before.7. Person X and Z both remember that being pretty mint in that other game, and they know it can be done, which means low risk.8. Everyone feels good as they write the tired, overused mechanic/scenario up on the whiteboard.9. Repeat.There is little to no way to get vision from a peer-only group unless they have worked together long enough that they are all on the same wavelength.There are two potential solves to this:1. Separate brainstorm and decision meetings.2. Employ a group design method I tested at Crystal Dynamics called a "The Thunderdome" (as coined by Mr. Ron Rosenburg.)Thunderdome!A "Thunderdome" gives each member of the level team the same deadline to propose a complete, individual solution to the entire design problem (in this case a paper map.) Once that (tight) deadline is up, the whole level team comes together and shows their individual solutions to their teammates, and everyone discusses the pros and cons of each one in a respectful way.Then the team (and the lead) cherry picks the best ideas from all the proposals and merges them into a unified team plan.This is the equivalent of forcing lateral thinking techniques in an individual. Humans naturally solve problems by brainstorming solutions until they find one that works, at which point they generally stop thinking about the problem. Lateral thinking techniques push us to go beyond that first working answer and try to find three to five more, to see if there is a better solution out there before moving on.When each individual in a "Thunderdome" creates their own solution, I guarantee that none of them will be the same, and the group will have multiple working solutions to pick from instead of one compromise solution. Of course this is not in the agile way -- which probably makes me a heretic who must be burned or something.Stage 2, Building Through FictionWith the Level Flow Diagram in hand, the next stage is to fill in the details.Architecting the level through storiesThis is the time to explore the level's stories because from them, the juiciest parts of the level's design will emerge.Regardless of the narrative of the game, each level has the potential to tell many layers of its own background story. Even an empty office has the potential to tell little stories that transform it from a dull set of plain rooms into a real place through artfully placed builder's tools, scrounged furniture, used cups, and discarded rubbish.But the real power of level stories has nothing to do with set dressing; it is in their ability to provide you with context-relevant gameplay scenarios that the story-based method really shines.To make the level real to the player though, first it must be real to you.A Cautionary Aside: Gather and Study ReferenceI would argue that the power to immerse the player, to absorb his attention completely, is the common attribute of the greatest and most successful games.Gathering and studying reference is critical to creating immersion for the player. It is something that the entire team should do, not just the artists.Everyone stores simplified constructions of reality in their mind; schemata that codify the critical features of the world around us. We use our schemata to recognize and interpret everything we experience.We also use those same simplified representations of reality to recreate it through art. Because no two people use precisely the same critical features to build their schemata, every person's art has a unique look, filtered through the lens of their uniquely simplified representations of reality.While schemata allow us to rapidly process the deluge of information we receive each day, they come with the cost of a blindness to data that does not fit with them. That data gets stripped away and left unprocessed. Because we rely on them constantly, we tend to trust them implicitly.But the fact that no two people have precisely the same schemata is all the clue we should need to realize that they cannot be trusted at all.When we are creating worlds in games, immersion is only possible for the player if we can convince the players that the space is authentic (whether stylized or not.) If the critical features on screen don't match up with the critical features of the player's schemata, then he or she will not be fooled by it.So as game makers we must have really precise schemata to convince the widest selection of players.When designers or artists rely on their standard schemata to judge their own creations, they are mistakenly assuming that others will judge their work using similar standards as they do. This can be particularly egregious when people from one country try to reproduce locations from another. American dumpsters sitting in the back streets of Paris or French road signs on the streets of Chicago might seem acceptable to the developers because they do not mismatch with their very simple schemata of those distant locations, but these contextually inappropriate placements will be laughably inaccurate to people really familiar with those places.Given that games are released worldwide, it is difficult to overestimate the damage to audience immersion and perception done by poorly researched levels for a large percentage of your audience. Remember, it's your worldwide reputation on the line.Case Study: Kung Fu Zombie Killer!!Blurb: When the living dead smash up his martial arts studio, Wu Shu master Ken Kong must punch, kick and chop his way through the zombie apocalypse while gathering humanity's remaining survivors on his quest to save the You Tube celeb of his dreams. Style:'70s exploitation movie visual themes mixed with a Japanese anime-inspired visual language. Highly stylized over-the-top combat, unrealistic physics, fun gaming conventions reign over realistic game rules. Street Fighter meets Pikmin in this zombie-filled romance beat 'em-up. Game Pillars:Fluid Environmental Kung FuThink Jackie Chan: Ken Kong picks up and uses everything around him to dispatch his zombie foes.Whether he is slamming doors into their faces, or ripping off one zombie's arm to bludgeon another to death, Ken Kong's simple multi-lock, rhythmic fighting system turns combat into a bloody storm of body parts and flailing fists.Protect the survivors!As Ken Kong saves the living from the living dead, they join the crowd that follows him, urging him on to greater feats of martial prowess. Different types of survivors can either bolster Ken Kong's abilities or can be applied to tasks throughout the game:Police - Shoot any zombies they see.Nurses - boost to Ken's health recovery.Martial artists - increased survivor resilience.Workmen - repairs.Geeks - hacking.Civilians - Cheering (boosts Ken's damage) and fortification building.Etc.The more there are of a given type of survivor, the better the crowd's abilities become. The crowd will stay together and can be ordered around by Ken, but they must be protected from being bitten by the zombies or the whole crowd could become infected.Secure each levelKen must shepherd the survivors to a location that can be fortified so that they will be safe.This could mean securing the entire level, or just one section of it. The crowd itself does the fortification, barring doors and boarding up windows. The more survivors there are, the faster repairs are done. Essentially they are closing enemy spawn points, and Ken must stem the flow of enemies while the fortifications are in progress or the crowd will be eaten by zombies.ThemeWhile the film Planet Terror is a good starting point for the mock '70s horror exploitation movie feel, Kung Fu Zombie Killer has a more lighthearted Viewtiful Joe feel at the same time.MotivationKen is in love with the YouTube vlogger jenna126xyz. In fact, he is her only fan. Throughout the game, Ken forces everyone he saves from the zombies to sign up as fans of jenna126xyz in an attempt to win her heart.Given the ludicrous nature of this game concept, it might at first seem that there would be little point in rigorous research or fictional development, but I contest that there still is.Even a world with a silly premise will resonate more fully when effort is made to realize it in its entirety.Example Level: Hospital Second FloorAfter watching jenna126xyz's most recent tearful videocast, Ken Kong is now trying to rescue Jenna's grandmother from a hospital overrun by the undead. The idea is that you see Grandma almost immediately, but can't get to her without the Hospital Director's keys, found near the end of the level, giving you an objective and a goal. The Hospital Director, on the bottom floor, will not come out of his secure office until the building is secure, forcing your secondary goal (save the survivors) before you can open the way to grandma.A Boss fight is worked into Grandma's room, and once that is done the level can pretty much end -- a fairly bog standard level flow.The section of the level we are going to focus on is the Second Floor, highlighted in red on the Level Flow Diagram above.A hospital is hardly an original setting, especially in this context. Hospitals are obligatory whenever there are zombies around: Silent Hill, Resident Evil, Left 4 Dead, and Planet Terror are just the tip of the iceberg. So the challenge is to walk this well-trodden ground and still make something somewhat fresh. The key to that is to look around you.Preparation: Designing from lifeWhen deciding how to tackle this hospital level, it would be tempting to begin by looking at the many other examples of hospitals in competing games, and while it is useful to learn what has already been done, it wouldn't help us get original ideas for this particular level.You are likely to be able to rattle off a list of areas from your head that you would expect to find in a hospital, from waiting rooms and restrooms to operating theaters and canteens. Most likely the overriding impression you will have in your mind will be long, seemingly endless hallways with single or multi-bed wards off them.But when you actually go to a hospital, there is so much more to see. There are gift shops, libraries, kitchens, rehabilitation areas with gyms or pools.There are auditoriums, children's play areas, janitorial closets, elevators and their associated maintenance areas. There are courtyards, roof gardens, underground parking lots, and changing rooms for the doctors and nurses, with lockers and showers.You also see just how many more off-limit areas there are than public ones. Some are secured with passkeys, others with ordinary locks.These locked doors lead to record rooms, office spaces, drug and equipment storage rooms and all manner of other administrative areas. Their doors are either solid or have very small reinforced glass windows. A great deal of research can be done from books, movies, and the internet but nothing can replace personal experience. While not everyone can go to the pyramids or an abandoned space station whenever they feel like it (unless you're Richard Garriott, of course), most people could visit an abandoned or ruined place near them (as long as is safe to do so) that will evoke a similar mood and mystery on a smaller scale. For our purposes that means there are many places where people could potentially survive a zombie attack, along with lots of opportunities for us to realistically gate the player. The key is you must look, in order to find inspiration. The trap of arbitrary spaces There is nothing more amateurish than arbitrary architecture, by which I mean spaces obviously only built for the player by the game designer. Whether it is a city street or an ancient ruin, it is the designer's job to build spaces with a fictional purpose as well as a gameplay purpose. When a player enters a temple that has no space for worship, or a tomb with no burial chamber nor rhyme nor reason behind its layout, he or she will not be convinced that they are exploring a real place. The worst starting point for a level is a series of featureless, functionless boxes joined by corridors into which gameplay is inserted from a list of gameplay goals. Levels built that way may as well be randomly generated. Even if you are creating an outside space, studying ordinance survey maps to see how real world topology looks and going for a stroll in the hills will let you turn a bland height map into a believable outside space. The difference between a height map that has been pulled up and down randomly, and one that appears to have simulated real weathering is enormous. Looking at real spaces for inspiration will bring the physical rules of building construction to the forefront of your mind, it will inevitably bring truth to your work and give you ideas that you would not otherwise have thought of. You must design the spaces of your level primarily for the people living in the game world and then adapt it for the player. Starting Point: Floor Plan I'm going to use this section of a hospital floorplan, based on a general admissions unit from a real hospital, to show how one floor of the level might be constructed through fiction. First off you can see that while the majority of the areas are not designed for the public to wander around, access to them is relatively easy. For instance, the admin area is easily accessible by climbing over the reception desks from the waiting room, even if the two doors were closed and locked. The only rooms that are likely to be kept locked at all times are the workrooms, the records room, and the storage room. They would most likely have keycard or combination locks so that staff could relatively easily get in and out but patients couldn't wander in willy nilly. The examination rooms would most likely have been unlocked when the zombies arrived, but along with the nurses room, the manager's office and the W.C, they could have been locked by survivors trying to escape the living dead. Red and Blue Keys There have been an untold number of physical key card puzzles in games, and almost as many broken-down elevators. The hardest challenge in design is avoiding the clichés when trying to disguise the keys and locks in the levels. Kung Fu Zombie Killer is a beat em up, so most rooms on this floorplan are probably too small to fight effectively in. The rooms can be scaled up to an extent without becoming ludicrously oversized, but it is general note that as games lean towards more believable spaces there is a greater need for better camera and animation systems to cope with confined spaces. The reality is that without unique abilities, there is little that hasn't already been done a hundred times when it comes to player gating. The standard options have been so thoroughly explored, re-dressed and reskinned, that many games these days have simply begun to do away with them altogether. Games like GTA let you go almost anywhere and attack problems from any angle. Their gates are metagame gates; the beginning and end of missions, the opening of new city areas. They don't struggle to mask the opening of the game world in fiction -- they make it very clear. I'm not arguing for one way or the other; both can be done well or poorly. In this game, I'm using NPCs as keys; they are keys that can be eaten by your enemies. If your keys die, then you won't be able to achieve some (or potentially any) of your goals. Populating the level Now that we have a better understanding of our location, it is time to look to any ramping documents and decide what sorts of scenarios have to be fit into the level. Kung Fu Zombie Killer's NPCs are also used as the game's help system, pickups, power-ups, quest givers, quest items, achievements, secret items, traps and puzzles. They are ultimately flexible from a gameplay point of view, but even better, they add life and narrative to the game. We want to place the following in this section of the level based on a ramping plan: NPC's to save: • A security guard - who shoots zombies and has a security pass • ~2 doctors - who heal the crowd and lower chance of crowd infection • ~4 nurses - who increase Ken's health • ~18 civilians - who contributes to Ken's damage bonus by cheering Items to use: • toilet • letter openers • sinks • heavy swinging lamps • dishes of scalpels • table lamps • windows • flower pots • wooden chairs • head-height glass cabinet doors Zombies to Kill: • Tons of them. Sculpting the play path When working into realistic spaces the first thing to do is work out how much you want to modify the physical flow from room to room. This comes down to how linear or open you want a level to be. For the sake of this example we are going to funnel the player fairly heavy handedly just to illustrate some of the ways it can be done. In this case I used two standard techniques; the permanently blocked door and the hole in the wall. The fiction for these changes is fortifications that are so drastic that they can't be undone, and walls that a large number of zombies have burst through. These two types of permanent changes to the floor plan can dramatically change the way you move around a realistic space. The first step is to define the primarily play path. I have funneled the player in a big circle all the way round to the storage closet above the entrance, where the security guard is hiding with a nurse. The security guard is necessary to unlock the door on the east wall, the only way through which you can reach the staircase and exit this floor. The barricades can be disassembled by any survivors if you approach from the side where the crosses are. The fortification point is this floor's zombie spawner. Ken has to fight on the patio while the survivors build the barricade, before jumping back into the building at the last second. The more survivors Ken has released, the faster that the barricade can be built, but the player needs to make sure that there are no (or few) zombies left inside the building because the survivors are vulnerable while fortifying. Everything else is fairly self-explanatory; there are four bonus civilians and a nurse that can be unlocked from the manager's office if the player backtracks with the security guard, lots of zombies to kill, and a second barricade that can be dismantled to create a shortcut if backtracking is necessary through this space. Set dressing The simplest examples of level stories are told through the "forensic" placement of art; bloody hand prints on the walls, discarded children's toys, and overturned tables and chairs. They don't affect gameplay, but they provide mood and richness to the level. For masterful use of storytelling through set dressing, look at Fallout 3. Every area had its own stories to tell from depravity through to insanity, all laid out in the artful placement of everyday objects. Those small forensic clues can be expanded to full narratives describing the fates of characters you may never meet in the game. For instance, you might find graffiti scrawled in blood on the walls describing somebody's final moments, but finding a room with its doors off its hinges, a toppled pile of tables and chairs just behind it and a fat, satisfied-looking zombie sitting in a puddle of blood, tells a similar story while also offering you the chance to respond. This level is filled with possibilities for those details and they can all be pulled out of the backstory of these survivors. The Backstory As I sculpted the play path I wanted, I was coming up with the following back story: Zombies first came into the waiting room from the stairwell. The security guards managed to fight them off and managed to permanently block that door. Meanwhile, two patients ran and locked themselves in the toilet. Next, zombies started coming in through the entrance. The hospital staff moved everyone out of the waiting room and barricades were set up trying to secure the admin area. Meanwhile, the zombies in the stairwell manage to smash through a wall into one of the examination room. Another permanent barricade was set up, and just to be sure, a security guard locked the next examination room's door as well, just to be safe. By this point zombies have started climbing over the reception desk and break through the right hand door into the admin area. Everyone evacuated further back into the offices except one doctor who hides under a desk. A nurse was already hiding in the manager's office, and she let four patients in as the zombies swarmed the admin area. The rest of the survivors ran towards the patio, but a mass of zombies smash their way in through the patio door and the survivors find themselves surrounded. Groups crush into any nearby room and lock the doors behind them, leaving some unlucky people locked out in the corridor. Almost the entirety of this story -- plus the stories of the other humans that didn't survive this attack -- can be carefully laid out in the artwork. The more questions you ask, the more stories can be hinted at: • Is there a reason that the security guard ends up with that particular nurse in the storage room? • Is there a reason why one nurse has access to the securely locked manager's office? • Who shut the door of the North East workroom, shutting the zombies in there with a group of (now dead) nurses? The upshot of using this method will be a sense of authenticity during play that you cannot achieve any other way. While players may not consciously pick up even half of the detail you are putting in, they will feel it. They will be drawn into your world in a way that more laissez-faire methods simply cannot achieve. Thunderdome Part 2 Now, were I a member of a level building team, the map I've created above and the back story that goes with it would be presented along with all the others: one from each team member. They would be reviewed by the whole level team, who having all thought it through deeply, are now informed critics, under the watchful eye of the lead that wrote the Flow Diagram. Each design would be unique and all would have their plusses and minuses. No one design will be so perfect that it will be better than everyone else's in every respect. I know there would be better ideas on the table than mine because I work with talented people. But perhaps some of my ideas would be end up being selected and they would go into a final level layout that would be better than anything any one of us could do alone. Fact. And that's magic. Summary • Research thoroughly; there are many people who will know if you skimp. • Always visit a real location for inspiration. • Always start from an architecturally sound floor plan. • Sculpt the play space with events that occurred before the player arrived. • Define the back story through the design and let them feed each other. • Write down the back story so that as the design is realized on screen; all departments can express it through art, animation, and sound. *Note: This article is posted on Next Level Design with permission from the author Source: http://www.gamasutra.com/view/feature/132801/action_adventure_level_design_.php Follow TobyWebsite: www.focalpointgames.comTwitter: https://twitter.com/mechabadger Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  8. People ask me sometimes where my ideas come from. Well, that’s not exactly true, nobody asks me that, but all kinds of famous people say people ask them that so I figured I’d jump on the bandwagon. But if they DID ask me, this is what I’d say (at least as far as level design). I design a level one “setup” at a time, then I link all the setups together to form a level. When I’m thinking of a specific setup, here is the basic process I go through: WARNING: GET READY FOR A TON OF BULLETED LISTS AND SENTENCE FRAGMENTS!!! Bullets R Boring! Gimmeh some pictoorz! Intensity Curve How many setups are in the level? On a scale of 1 to 10, rate each setup in terms of how intense (difficulty + energy) it should be. These numbers should go up over the course of the level, but we should have some noise in this regard (see image below). "Interest Curve" As defined by Jesse Schell in The Art of Game Design: A book of lenses Difficulty / Intensity Where is this setup located on the “intensity” curve of the level? Does the intensity curve want a combat setup or a non-combat setup here? If we want the intensity to die down a bit, non-combat setups help with that. If it’s a combat setup, based on the intensity curve, determine the number of enemies and the combination of enemies in the setup. Never repeat a setup. Always introduce an enemy before you use multiples of that enemy or use the enemy in combination with other enemies. (Enemy A, Then Enemy B, then two A’s, then an A with a B, then two Bs, then two As and two Bs, etc). Choose the enemies based on “archetypes” (see below). Terrain Features Gaps: Horizontal separators. Need to determine: Width The path around or over the gap The fiction or type of the gap (cover, a river, a pit, etc…) Ledges: Vertical separators. Need to determine: Height (usually in two increments: Short and Tall) The path to the top of the ledge The fiction or type of the ledge (a car, a balcony, a platform…etc) Gaps and ledges Area Shape Determine the size (Should it feel tight, normal, or vast) Make sure enemy entrance or spawn points are visible from the player’s entrance point Reveal VS Recon (Is the player surprising the enemies or are the enemies surprising the player. This should vary based on the intensity curve) Make sure the area contains or has a view of some kind of focal point. The action should revolve around or serve to frame this visual focus. Tight Space Enemy Archetypes Near: Attacks close-up Far: Attacks from far away Heavy: Can be near or far, but should be player’s top priority if all else is equal Popcorn: Can be near of far. Not dangerous unless in groups. Should make the player feel strong. Near / Far / Swarmer / Heavy Enemy Idle Behavior If the player is surprising the enemies, what are they doing before he triggers them? (Patrolling, idling, juggling, etc…) Enemy Intro Behavior How is the enemy introduced? Spawn-in: The enemy appears (Teleport, jump in, etc) Run-in: The enemy comes in from off-screen (run ,fly, etc) None, the enemy is already there when the setup starts These should be varied based on the intensity curve. Enemy Trigger Zones Where does the player have to be for the enemies to activate and begin attacking? Where does the player have to be for the enemies to stop following him once they’re activated? Where does the player have to be for the enemies to deactivate? Enemy Location / Placement Must be visible to the player from the entrance to the area Do we want enemies to clump or be spaced out? Are the enemies close to or distant from the entrance How close or far do we want them from terrain features? (Over a gap, up on a ledge, behind cover, etc…) Place important items E.g. Explody barrels, health, etc Usually place close to a wall or suggestively (an explody barrel right next to a group of guys) Coin placement! Place gravy items Rewards: (Crates, coins, etc) Pure gravy: E.g. Breakable scenery Visual gravy: Non-breakable scenery, usually to provide movement or points of interest. (Blinky lights, scrolling water, plants, etc…) 'What are you trying to say? That I can stop bullets?' Source: http://www.ongamedesign.net/when-im-designing-a-level/ *Note: This article has been posted in full with permission from the author Follow Mike Website: http://www.ongamedesign.net/ Website: http://www.chaoticstupid.com Twitter: https://twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  9. In this article, originally posted on Bungie.net, Chris Carney, designer at Bungie for 15 years, shares some insight into the level design process used to create the Halo: Reach map The Cage. His intent is to provide food for thought for those jumping into Halo's Forge Mode, but it's most definitely applicable to anyone with an interest in level design.The article starts off at...well...the start of the design process: Chris suggests starting out by answering 3 questions: How many players is your level going to be designed for? What are the Primary and Secondary Gametypes that will be played on it? Will the maps have Vehicles? Of course, these questions may vary depending upon the game you're designing for, but you get the point. Once you have your answers, we move on to the initial design stage. The form this takes can vary greatly from person to person, so Chris suggests using whichever method works best for you. For the purposes of this article, Chris ultimately decided to use The Cage as his example level. He stated that it "started off as a small to mid-sized, 4 – 8 player map, intended for Team Slayer and map possession gametypes such as Stockpile that was going to use some ideas from Lockout and feature outer circulation similar to Ascension and the Pit." Chris then begins to systematically work through what he calls "the seven essential multiplayer design elements." Element #1: Simplicity Element #2: Orientation Element #3: Navigation Element #4: Flow/Circulation Now we get into the nitty gritty - the actual design process used for The Cage. Chris started out knowing that the level would consist of isolated combat areas, akin to Lockout. He explains that they used colored cardboard cutouts to start out, with green boxes representing rooms, blue rectangles being bridges, a yellow circle signifying a platform, and red circles designating alternative movement options (teleporters, lifts, jumps). Element #5: Hard Points Chris continues to share further iterations, along with supporting cardboard cutout images, which you can see by following the link at the end of this post. And then he comes to the next of his seven essential elements. Element #6: Layout of Game Objects Which brings us to the final critical element. Element #7: Iteration After this brief interlude to finalize his list of essential elements, Chris returns to The Cage. And finally, we get to the editor. Chris jumps into forge and begins constructing his well prepared level, making various further adjustments as he went along. As was the case earlier, Chris provides more detail on the iteration process, which can be seen in the original article. And with that, we reach the end of our lesson. Read the full article here: http://halo.bungie.net/News/content.aspx?cid=29601 Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  10. Next Level Design has been given permission from the author to host this entire book in PDF format. Download the attached PDF at the bottom of this article for the entire book, or view it here: https://drive.google.com/open?id=1uB3pUjPkHuWWOYEc70nkVjVlR09ua70zStill not sure? Read through this section on lighting that was recently posted on Next Level Design: In addition, we've included another small section of the book right here: pg. 25 INTRODUCTION Due to games’ ever-increasing complexity and the expanding nature of levels in general, it can certainly be said that levels are not easy to design. Levels, as said before, are combinations of dozens of different aspects, the conglomeration of which render them complex by nature. This combination of complex systems itself requires good design from the start in order to avoid an inconsistent and downright messy result. Because the different aspects are so interdependent, it’s very important not to lose sight of a level’s ‘big picture’. This chapter highlights some of the issues that can pop up when designing a level, as well as some more minor aspects to keep in mind. The overall design is the foundation for a level. Without a clear, strong design, there is no solid base on which to build the level. THE CREATION OF A NEW WORLDThe most important part of a successful level is its beginning. The way a level starts will determine a great deal about how the rest of the level will evolve and how quickly. In these days of growing complexity, efficiency and speed are valued highly. Getting off to a bad start or using bad work methods can cost time which is usually at a premium to begin with. Part of starting a good design is foreseeing potential problems before anything is created. By doing this early in the process, a good level designer can quickly and easily modify the design to better fit the available time, workload, difficulty, technical limits, or all of the above.How one begins a new level is different for every person. One designer may write everything down in a design document while another, like me, just plans it out in their head. The method used also depends upon if one is working in a team environment. Working with a team means that the level’s design must be communicated throughout the team which usually means some sort of written, drawn, or quickly modeled design that can be passed around and/or presented. How it’s done isn’t important as long as several key aspects are kept in mind and the end product is of a sufficient quality. If the technology used cannot create lush jungles, for example, then this must be recognized before starting.A design should progress only when exactly what is wanted and how to accomplish it is known. Exact information is the key to this. Again using the jungle example, one must know what the jungle will look like, the colors it uses, the overall style, how the player will move through it, if the engine can render thick vegetation, what kind of physics will be involved, and too many more to list here.To assist in this task, I have developed a type of checklist that is at the base of everything I design. The list compares several key values against each other to see if they are possible and if they should be modified. It also helps define the values better. The list checks to see if the rules of, for example, lighting and composition are contrary to each other and if the goal is possible and what direction to take. This extensive chapter will mostly be about the latter.A level is complex and it takes increasingly more time and effort to successfully complete one; thus failure is not an option. All the areas that could potentially cause a problem should be identified before starting any work. Once the design process starts it should go smoothly; design dilemmas should not occur or, if they do, should be easily overcome with few modifications to the overall plan. Getting stuck can be very demoralizing and time consuming. pg. 26THE CHECKLISTA level always begins with a goal, a theme, or both. The goal may be that the game requires a medieval castle, or that it’s missing an ominous environment, or that the level is to be the central hub of the game.After identifying the basic idea, certain key information needs to be pinned down before starting the level. This ‘key information’ will be referred to as ‘the keys’. The keys communicate important properties about the level. They are the key words the level is built around and provide more information on the level’s requirements.The following are questions to determine the key information for the level-to-be: • (1-Time) How much time is there available? Is there a deadline? • (2-Tech) What tools and game engine will be used? • (3-Limitations) What limitations are there? Is there a shortage of art assets or staff/personal skill limit? Can anything be made or are some aspects beyond the scope of the project because of their complexity? • (4-Requirements) What kind of requirements are there? Are there any specific elements, for example, special buildings or areas that have to be in the level? When compared to the rest of the game what visual style or theme must the level adhere to? • (5-Purpose) What is the overall purpose? For example, is it a multiplayer practice level or a singleplayer boss arena? • (6-Gameplay) What should the gameplay be like? How should it be played? Should there be enough room for a large boss encounter? Or does it need to be large enough to contain a large number of enemies attacking the player? Perhaps it’s a vehicle level? Or it is a stealth level? And so on. • (7-Theme) What theme and/or style will the level have? Will it be a castle or a jungle? Will the style be cartoonish or realistic?This is all essential information for a level. The order of the list is not as important as the answers. Once the essential elements of the level have been identified it can be run through a checklist to see if it holds up. Will it work? Look right? Play right?The keys provide the information while the checklist determines if it is possible or not. The checklist combines two or more keys in order to determine if they fit together or not. If the desired theme is a jungle, but the engine can’t handle rendering dense vegetation, then these are two keys that do not fit together and the design will need to be adjusted accordingly. This is the type of information the keys provide: essential information that design decisions can be based on before actually starting work on a level. Thinking ahead is the key to success.The checklist itself is a system for asking questions and making comparisons. The questions are different each time, but the comparisons remain the same. Verify that the individual elements compliment each other.Here's the entire Table of Contents: Download the attached PDF below, or view it here: https://drive.google.com/open?id=1uB3pUjPkHuWWOYEc70nkVjVlR09ua70z *The Hows and Whys of Level Design is hosted on Next Level Design with permission from the authorFollow Sjoerd De JongWebsite: http://www.hourences.com/Portfolio: http://www.hourences.com/portfolio/Twitter: https://twitter.com/HourencesYoutube: https://www.youtube.com/user/Hourences/feed The Hows and Whys of Level Design.pdf