Search the Community
Showing results for tags 'counter strike'.
Procedural Content Generation (PCG) is a process through which FPS levels are transformed over time, with those changes being affected by the players in the game. In this piece, Peter Thorup Ølsted, Benjamin Ma, and Sebastian Risi have documented the findings of their research on 'Interactively Evolving Multiplayer Maps'. The following is shortened version of the Thesis from Peter, Benjamin, and Sebastian. The full thesis is approximately ten times as long as what's included here. There is an attachment which allows you to download the full thesis, which I urge you to do if you find this subject to be of interest. The Thesis is shared in accordance with Creative Commons Guidelines, and with full permission from the authors, who have been most generous in sharing their work. Abstract: Traditionally a dedicated level designer has to create every aspect of a level by hand, distribute and gather people to test it. Especially for multiplayer maps, the cyclic process of developing and testing can be quite cumbersome and time consuming. This paper presents a novel approach to provide live generation of levels for such multiplayer maps through procedural content generation and interactive evolution. The approach is demonstrated in the FPSEvolver video game that aims at replicating the look and feel of popular games like CounterStrike. Without leaving the game a group of players can generate, play and improve levels to fit their particular preferences by voting on a selection of evolving levels. This approach focuses on maintaining the level design principles for modern first-person shooters that encourages good engagements between players, in the popular game mode “bomb defusal”. The presented approach can generate enjoyable maps that adapt to the preferences of players across a range of skill levels. Several distinct types of levels were created during testing, which range from open to closed, and complex to simple, each fitting closely with what the different players consider a good map. I. INTRODUCTION The first-person shooter (FPS) genre has increased in popularity over the years, especially in the competitive scene that embraces the fast and precise gameplay. However poor level design can quickly turn off players. Developers often attempt to provide as much content as possible in multiplayer modes to keep players engaged, but designing even a single level can be very time consuming. After the level has been mockedup, user feedback needs to be gathered before the level in its final state can be build. Targeted playing styles can vary greatly for different levels, and by designing for all styles at the same time, a designer might end up prioritizing differently than what the player prefers. Additionally, depending on their skill level, different players might favor maps with very different complexities or other particular qualities. A promising technique for automatically creating new game content is procedural content generation (PCG; , , ). In PCG-based games the content can either be created before the game starts or when needed as the game progresses. Especially evolutionary computation and other search-based approaches can save on development costs when combined with PCG. The approach presented in this paper aims at generating multiplayer levels that tie in with the state-of-the-art gameplay and level design of games like Counter-Strike and Call of Duty . While PCG algorithms have been applied successfully in a variety of different domains, PCG in multiplayer FPS games is less explored and faces some unique challenges. In contrast to single-player games, multiplayer games allow for interesting social interactions as they provide a context for human interaction . Multiplayer FPS gameplay is often acted out on the same maps repeatedly, while most singleplayer games feature a narrative that tends to be played only once. Thus players in multiplayer games can become highly familiar with the provided maps. Repeated play also encourages players to learn to predict the movement of the opponents, which in turn rewards strategic planning. However, while some players prefer to play the same level over and over again, others might rather play new maps or variations of known maps that offer the right balance between familiarity and novelty. Creating variations on a theme is a property naturally supported by evolutionary systems. Thus, the combination of search-based PCG algorithms together with interactive evolution offers a new intriguing opportunity for FPS map creation: By allowing a group of players to interactively and collectively evolve multiplayer levels through voting, they can guide the evolutionary search towards map content they prefer. Importantly, the players can decide themselves how familiar or how novel the level to be played next should be. The main result is that players are indeed able to create levels that often match the preference of the particular group of players, from open to closed levels or complex to simple ones. Additionally, players generally report that the quality of levels improved as the game progressed. The results show that it is possible to automatically create maps for a multiplayer FPS game that players rate as enjoyable, thereby opening up an exciting new direction for PCG-based video games. II. BACKGROUND PCG allows game elements (e.g. maps, textures, items, quests, etc.) to be generated algorithmically rather than through direct human design , . This approach can reduce design costs and can also benefit players by providing them unique experiences every time they play. For example, the popular Diablo series features procedurally generated dungeons that players explore as a central focus of the game. Like Diablo, many other PCG approaches similarly rely on a fixed set of parameters and randomness to generate content within a heavily constrained space of possibilities. However, a recent focus is to apply artificial intelligence approaches to enable more open-ended generation of PCG. In particular, evolutionary computation and other search-based approaches  can limit the need for hand-designed rules, and may thus further save on PCG development costs. More interestingly, it also enables design of new content outside the scope of a fixed space of rules. One popular technique is interactive evolutionary computation (IEC ), in which the user in effect guides an evolutionary algorithm. An example of IEC applied to games is provided by NeuroEvolving Robotic Operatives (NERO ), in which players guide the evolution of a team of fighting robots. In another example, Galatic Arms Race (GAR ), weapons are evolved automatically based on user behavior. Further examples include Avery et al. , who evolved several aspects of a tower defense game, Shaker et al.  who evolved levels for the platform game Super Mario Bros, Togelius et al. , who experimented with evolving the rules of the game itself, and the social game Petalz, in which players can interactively evolve PCG-encoded flowers , . Only a few examples exist of PCG methods for FPS map generation. Cardamone et al.  tried to generate interesting multiplayer deathmatch levels with simulated agents. In their work the fitness of a map is determined based on how long the bot survived after it engaged the enemy. While the maps generated in Cardamone et al.  might be fitting for deathmatch play, they are less suitable for a Counter-Strike like gameplay. The levels contain dead ends and no specific areas are more dedicated to engaging opponents than others. On the other hand, the approach presented in this paper tries to create maps that funnel players towards likely engagement locations. More importantly, while Cardamone et al. evolved levels guided by a fitness function, the levels in this paper are created through IEC by a group of players. The promise of this approach is that it should allow the system to generate highquality levels that adapt to the players’ preferences across a wide range of skills, guided by their personal preferences. III. APPROACH: INTERACTIVELY EVOLVING MULTIPLAYER FPS MAPS In this paper maps for a novel FPS game, called FPSEvolver, are interactively evolved by a group of players. The basic game loop proceeds as follows: (1) Players select a map from a list of PCG generated maps by voting on them (the map with the highest number of votes is selected), (2) players play the map, and (3) variations of the played map are evolved and presented to the players. The idea behind the presented approach is that players can decide together in which direction the evolutionary search should proceed. In this way, the system should be able to evolve levels that match the particular skill level and preferences of the group. Interesting questions in this context are if the group as a whole can guide the search to maps that most players prefer and if reaching consensus through a voting process is possible. In addition to creating maps tailored to a group of players, PCG also offer a constant stream of novel maps that should help in keeping the players engaged longer. In multiplayer FPS games, many different game modes exist that differ in how the game is played. A game mode made popular by the video game Counter-Strike is “bomb defusal”, in which an attacking team of players tries to plant a bomb that the defending team has to defuse. This particular game mode was chosen for the experiments in this paper because it encourages more tactical planning and teamwork than the basic deathmatch mode. It is advantageous for either team to quickly familiarize themselves with the level to gain an upper hand in confrontations, by taking alternative routes for flanking or simply the shortest path. When killed, players do not spawn before one team wins. At the beginning of the round the bomb is given to a randomly chosen player of the attacking team who then has to plant it in one of the two predefined plant locations. If the attacking team successfully plants the bomb, they have to prevent the defending team from defusing it for a certain amount of time until the bomb explodes. If the bomb is not placed and all players on a team are killed, the surviving team wins. After a few rounds, the two teams are swapped, making the attackers the new defenders and vice versa. A. Game Development FPSEvolver’s basic game mechanics are built on a pre-made and easily modifiable system for the Unity Game Engine, which provides modern shooting- and movement mechanics. The Realistic FPS Prefab has most of the features needed for a FPS game and resembles Counter-Strike and Call of Duty in both visual elements and gameplay. Local networking is handled using the standard solutions in the Unity Game Engine. Figure 1 shows an example of the player in the game. B. Key Principles in Good Multiplayer Map Design FPS maps follow some relatively simple but effective guidelines. In order to create engaging maps through a PCG-based approach, it is vital to understand what these guidelines are. In this context, we introduce the term the good engagement (TGE), a level experience in which the intended strategic and skill-based gameplay shines through. TGE does not mean that the game is fun to play, but rather that the level design supports and encourages interesting choices, from which a fun gameplay experience should emerge naturally. In this paper, the map representation (explained in Section III-D) and the maps shown to the player to pick from are influenced by TGE. Fig. 1: First-person perspective from the developed game FPSEvolver. The game aims at replicating the look and feel of popular games like Counter-Strike and can be downloaded from: sebastianrisi.com/software/ In good “bomb defusal” maps the bomb positions, spawn points, paths and choke points should be placed in a balanced way. A level should offer different types of engagements to suit a variety of playing styles. Because some players prefer sniping from long distances, while others prefer quick reflexes in close encounters, a map should have short, medium and long engagements. For example in Counter-Strike interesting choices often occur around the choke points (i.e. areas where the two opposing teams will likely encounter each other). At the start of each round the two teams have to decide at which choke point they want to engage the enemy. The defenders can normally reach the bomb positions before the attackers arrive and it is usually possible for the attackers to get to another choke point without confronting the defenders. The exact locations of engagements change slightly depending on the play style of the teams. In terms of the playing experience, the choke points are map locations with a high probability of encounters; this is where the fun in the game lies for most players. Since most levels only have two to four choke points, the number of sensible strategies for each team are limited. When building competitive levels, determining the location of choke points is one of the keys to good engagements between players. Playing a map repeatedly gives players a familiarity with both the map and how it is usually played. With this knowledge the player can make “interesting” choices about how, when and where to engage the enemy to create an advantageous situation. In the “bomb defusal” mode it includes when to plant and defuse the bomb in safety from the opposing team. The levels in Counter-Strike are often constructed using very angular designs in the overall layout, thereby highlighting the paths of the map. An interesting observation is that levels created for “bomb defusal” do not feature four-way intersections, since they would provide players with too many choices when moving towards their target destination. Call of Duty has both levels that are very open as well as corridorbased; Counter-Strike is almost exclusively corridor based. Our analysis of Counter-Strike and Call of Duty maps and their multiplayer gameplay revealed five key aspects when designing levels for “bomb defusal” modes. These rules are what we determine important to maintaining TGE in procedurally generated levels: Maps should always have a few choke points, which the teams can reach at about the same time. Bomb locations should always be closer to the defending team, giving the defenders a small advantage. Bomb points, as well as spawn points, should never be visible from one another. Levels should not contain too many choices, especially in the form of four-way connections. Spawn points should be in opposite ends of the level to make sure that encounters do not start too early. C. Selecting and Evolving Levels Fig. 2: The voting system allows players to vote positively or negatively on any map. The map to the left depicts the parent to the six evolved offspring maps shown to the right. The map encoding is able to generate maps that show meaningful variations on the parent map, thereby allowing the players to guide the evolution of maps towards content they prefer. In the approach presented in this paper players can vote on a selection of six maps presented to them (Figure 2). Inspired by Cardamone et al , players can rate levels by either a thumbs up or down indicating their preference. After the players are done voting, a score is calculated for each map based on the votes of all the players in the current group; a positive vote increases the score of a map by one, and a negative reduces it by one. The map with the highest score is chosen as the next one to be played. A video showing the voting process together with footage from a two-player match can be found here: In order to not present the players with particular bad levels, new levels are generated until six levels are found that adhere to the rules of TGE. In particular, the filter removes levels with (1) too long corridors without any choices (longer than 30 game units), (2) spawn points that are immediately visible from one another, (3) bomb position too close to one another (less than 20 units), (4) imbalanced maps where one team has a clear advantage (more than 85% of the level is closer to one team), (5) spawn points that are not reachable from one another, and (6) levels with either too high or too low map complexity C, which is calculate as: C = n + r, (1) where n is the number of three-way connections and r is the number of room entrances/exits. A refresh button is also part of the interface, allowing players to generate a new set of levels if they are not satisfied with the current selection. The button follows the same voting rules as the levels (i.e. it needs the most votes in order to be activated). To ensure that levels always improve in a lineage, players are ask if the current level is better than the parent level after each match. If the new level is deemed better the lineage continues with the current level. However, if the level receives more negative than positive votes, the lineage reverts back to the parent, and only progresses once a better offspring has been found. A summary of the game flow is shown in Figure 3. Fig. 3: Flow chart of the game’s progression D. Map Representation and Generation In search-based PCG the representation should allow a variety of different maps to be expressed, while also generating maps that appeal to the user. The general aim of the developed map representation is to resemble the layout and perpendicularity of Counter-Strike levels. The basic building block of the map genotype is a list of pairs of two-dimensional points (which can have variable length). Additionally, the genotype specifies if these pairs of points should be connected first via a horizontal or a vertical line (Figure 4a). The resulting Lshaped corridors are snapped to a grid to ensure that nearby shapes are grouped together (Figure 4b). The size of the map and the grid resolution are also encoded in the genotype. Once all the pairs are connected into L-shapes, the lines begin to resemble the structure of a level. To conform with the TGE rules established in Section III-B, the algorithm modifies these genetically determined shapes. In the first step all dead ends are eliminated (Figure 4c) and four-way connections (a) L-Shapes (b) Snap to Grid (c) Dead-end Removal (d) Four-way Removal (e) Dead-end Removal (f) Corridor Carving (g) Open Space and Props Addition (h) Spawn Positions (i) Bomb Points are reduced to three-way connections (Figure 4d). Similarly to the setup of Cardamone et al. , the layout is then carved out from an all-black and impassable space (Figure 4f). Corridors have a variable width that is part of the genes encoding the L-shapes. Areas, which are also encoded in the genotype by their position, width and height are carved out as rooms (Figure 4g), and props (e.g. crates to hide behind) and doorways (encoded by their position, the relative width of the opening and the direction that the doorway is facing) are placed in the corridors. Spawn points are positioned as close as possible to their encoded position (Figure 4h). The generated level layouts are then analyzed, to determine which team is closest to each position in the level. This analysis also determines the location of possible bomb positions, which should be reachable faster for the defending team than the attacking team (Figure 4i). From this list, two bomb locations are chosen, based on an integer value encoded in the genotype. Fig. 4: The different stages of the level creation process. See main text for details. Mutations on the genotype can create new L-shapes, remove existing ones, create new props or modify the values of existing items. Figure 2 demonstrates that the encoding can generate levels with modest and more significant phenotypic changes that resemble the parent level to varying degrees. Importantly, small changes in the map’s genotype typically produce small changes in the resulting phenotype. Additionally, while less polished, the maps resemble the layout and perpendicularity of Counter-Strike levels (Figure 5). It is important to note that the encoding is deterministic, since all the values necessary to create the map are encoded in the genotype itself. Fig. 5: Example of a map interactively evolved by a group of players in FPSEvolver. IV. EXPERIMENTS A total of three playtests were conducted with players who had at least some prior experience with FPS games (Table I). For the second (pt2) and third playtest (pt3), the testers filled out a questionnaire after they played the game, while the first playtest (pt1) served only as a verification of the technology and no data was recorded. The quantitative answers were either yes-no questions or a rating between 1 and 6, where 1 was the lowest and 6 is the highest score. The maps played were recorded for pt2 while every map, vote, rating, kill and death was recorded for pt3. The second playtest had session with three separate groups of four to five people (pt2.1, pt2.2 and pt2.3), each lasting 90 minutes. For the first hour the groups played the game and evolved levels. Every sixth or seventh generation the game was reset to start a new lineage of maps. After an hour of playing the game, the participants filled out a questionnaire. For pt3 the mutation probabilities were increased slightly, and the voting system was altered, allowing players to vote on the map first and then on the bomb position. Additionally, while players in pt1 and pt2 were only allowed to vote for a single map, the final voting system allowed them to rate multiple levels. This change in the voting system aimed at minimizing dissatisfaction among voters . The third test focused on gathering relevant gameplay and player data, to analyze if there are any correlations to the questionnaire data. Votes and ratings were recorded to follow the progress of maps and how they evolved. A major change in the last test was the addition of a long-range sniper rifle, similar to the ones found in Counter-Strike and Call of Duty. The playtest had 13 participants that would first all play together (pt3.1). Afterwards the players were split up into two group based on their in-game score from pt3.1: the skilled players (pt3.2) and the less skilled players (pt3.3). Unfortunately, the final playtest suffered from unidentified network issues, which hindered the progress in some sessions. Therefore, the sessions do not contain as many generations as those of pt2. TABLE I: An overview of all playtests, their names, skill ranges and player count. V. RESULTS An interesting observation is that, despite a wide range in FPS experience, the groups were able to agree on a direction that the level design should take. Players with skills ranging from 2-6 (where 6 is highest) in pt2.2 and 1-4 in pt2.3 still managed to reach consensus, without the players explicitly agreeing on any design. Group pt2.2 reported a clear preference for open spaces in their questionnaire responses (Figure 7). Figure 6b, which shows the final map of pt2.2 suggests that the system is able to capture their preferences; the map has more open space than corridors. In fact, in the discussions following the test a player mentioned that the last level was particularly fitting with his preferences. In group pt2.3 (Figure 6d), the level did not evolve to something complex but instead to a smaller and simpler levels. This again was in line with what the players preferred, according to their questionnaire answers on what constitutes a good level. These results suggest that the evolutionary approach is often able to generate levels that fit with the preferences of the particular group of players. While the final maps of pt2.2 and pt2.3 matched the preferences of the players closely, the final maps of pt3 also matched the descriptions but not as accurately. This discrepancy is likely due to the limited number of generations that players were able to evolve maps for in pt3 (because of network issues only three generations in pt3 compared to six in pt2). The questionnaire in pt2 asked the players whether or not the maps’ quality increased over the sessions, whereas in pt3 we also asked if the maps got worse. Not a single participant felt the levels got worse and the majority of players stated that the quality actually improved over the course of evolution. The high number of positive ratings suggests that progressively likeable levels were created (Figure 8), even with many people voting at the same time. In pt3, the average player placed over 100 votes in total, with roughly 58 positive and 46 negative votes. The new voting system introduced in pt3 provided the user with multiple votes and increased the perceived impact for voting from 4.23 on average (sd=1.09) in pt2, to 4.8 (sd=1.34) in pt3. While not statistically significant (according to the Student’s t-Test), this increase could be explained by a minimization of dissatisfaction among voters . Fig. 6: The maps of the first and last generation for pt2.2 and pt2.3. The main result is that the IEC system can create maps that suit the preferences of the particular group. Players of medium skill (pt2.2) preferred open spaces, and disliked long corridors, and where able to guide the evolutionary search towards such a map (b). Players of low skill (pt2.3), on the other hand, preferred less complex levels and shorter corridors, which is also reflected in their final map (d). Fig. 7: The answers of players in pt2.2 on what constitutes a good map. The evolved map of the last generation can be seen in Figure 6b. Notice that every tester mentions open areas and how the final map contains many open areas. Fig. 8: Players for pt2 and pt3 were asked if they thought the quality of levels improved over time. The main result is that the majority of players agreed that the levels got better as evolution progressed. A. Level Complexity Not surprisingly, players of higher skill level tended to prefer more complex levels. The average complexity of a level voted on had a positive Pearson’s correlation coefficient of r=0.3 to the skill level of the player, indicating a weak positive linear relationship. Figure 9, which shows the complexities of levels as they evolve, suggests that there are different target complexities depending on the testers involved. While most maps saw some change in complexity as they evolved to fit with the overall preference of the players, the map complexity for pt3.1 with 13 players remained steady throughout the test. In pt2.2 a short increase in complexity can be noticed after which it settles at 17. What is not apparent from these numbers, is the increase of open areas in this particular playtest; the complexity metric only takes into account the amount of three-way connections and room entrances (Equation 1). Therefore, the addition of open areas does not necessarily change complexity significantly. For pt3.3 and pt2.3 a continuous change in complexity throughout the sessions is observed, with upwards and downwards trends. B. Player Satisfaction The overall player satisfaction appears to be quite positive. Almost all players agreed that the game was representative of an FPS, and the enjoyment of the game was high in pt3 and pt2, with an average score of 5.15 (sd=0.66) and 4.54 (sd=1.39) on a scale of 1–6. Correlations in the data show that there is a link between the player’s performance (measured in kill-death ratio), and the enjoyment of the game (r=0.58). Interestingly, there is also a clear correlation between reported player enjoyment and increase in reported map quality as the game progresses (r=0.87). VI. DISCUSSION AND FUTURE WORK The results from pt2 and pt3 suggest that the players’ choices actually allowed them to evolve increasingly better suited levels. The overall quality had an average score of 4.07 (sd=1.07) and 4.31 (sd=0.91) in the two tests on a scale of one to six. 61% and 77% agreed that the levels increased in quality during the test sessions. In pt3 we also asked whether or not the quality of maps decreased and not a single testers 1 2 3 4 5 6 21 19 17 15 13 11 9 Generation Complexity Level complexity thoughout lineage pt2.3 (simple levels) pt2.2 (open spaces) pt3.1 (no long corridors) pt3.3 (mix of open spaces and corridors) stated it did. The best levels received an average score of 4.8 (sd=0.97) and 5 (sd=0.78). The qualitative answers and the evolved maps suggest that FPSEvolver offers an interesting new alternative in the creation of engaging multiplayer maps. Fig. 9: The complexity of four different lineages across a range of skill levels. The preferences for each group are also shown. The first and final levels can be seen in Figure 6. More detail on the groups can be seen in Table I. The voting system for pt2 and pt3 changed between playtest. Instead of a single voting screen determining the layout of bomb and spawn positions, the bomb positions were now on a second voting screen. For pt2 and pt3 most players agreed on the question “Did you feel voting could impact the bomb positions?”. In pt2 23% of players did not feel they could impact the bomb positions, while only 15% in pt3 felt the same way. The fact that not all players agreed could indicate that the six variations presented where too similar to one another. As the bomb positions had to be placed closer to the defenders, it did only leave about half the map for the bomb positions, and thus not a lot of possibilities for variations. Correlations exist between the skill levels and enjoyment of the game (ranging from 0.46 to 0.61) and the personal perceived impact (ranging from 0.45 to 0.71). It is possible that a less enjoyable game experience is due to a lack in perceived impact when voting. Playing in the bigger group with 13 players in pt3.1, might have also negatively influenced the playing experience for some players. It is suspected that mixing players with extremely low and high skill levels provides less enjoyment for the weaker players. Thus, automatically matching players with similar skill levels could be an interesting extension to the presented system and is an area of active research . Additionally, the more homogeneous the group the easier it will likely be to guide the evolutionary system towards something the whole group prefers. For pt3 a long range weapon was added, which might have inadvertently increased the difficulty of the game. Experienced players now have more tools at their disposal, while unseasoned players are still left struggling with the default weapon. While most players in pt2 perceived levels, which contained long corridors as inferior, only a single pt3 tester did. It is possible that the inclusion of the long ranged weapon gave new purpose to these long corridors that had none in pt2, thereby changing the preferences of the players. In fact, the sniper rifle was included due to a number of players in pt2 complaining about long corridors, which is something that is not necessarily considered negative in Counter-Strike or Call of Duty. We sometimes saw widely different results between pt2 and pt3 in regards to the player’s reported enjoyment of the game, and in some of the correlations. It is difficult to conclude why, but we suspect that the treatments of the different playtest groups could have had an impact. For example in pt2 the three groups were all separated, unlike pt3 where all players would first play as a group. During pt3.1, which in part was used to determine the players’ skill level, an imbalance appeared early on in the team arrangements. These imbalanced teams likely decreased the enjoyment for weaker players that now lost more often. Additionally, the round duration was longer in pt3.1 and pt3.3, which means that players that died early had to wait longer to rejoin the game. Another difference in the two playtests was the delivery of instructions. For pt2 we had printed instructions, and placed them at each computer. In pt3 we had instead visual instructions in the menus of the game, which some players missed when entering the game. The instructions for the voting screens were delivered orally in both tests, but having a larger crowd of people was more difficult than anticipated, resulting in some players missing important information. The generated levels for pt3 have noticeably fewer generations per session than pt2. This makes it harder to evaluate the evolutionary progress for this playtest. Had it not been for network overload issues during the playtests, it is possible that the maps in pt3 would have been more in line with the results from pt2. Adaptation to group preferences seem to increase in general as the lineages progress. Additionally, a higher sample size would have been preferable to further verify the results with more than the 19 unique participating players. For the three playtests we invited people with different backgrounds and skill levels but all participants had an interest in games. A few players had very little interest in FPS games in particular, but everyone was familiar with how to play them. During the play test we only distinguished between skilled and low-skilled players. Some players had a background in game development and some with level design experience. Some testers were skilled FPS players but did not have any game development background, while others had a level design background with poor FPS skills. Some testers were also returning from pt2, and others had only tested the game once. Despite the mix in player skills, the results indicate that players can eventually reach an agreement in which direction evolution should proceed. However, tests with very specific skill levels or preferences might have yielded a much more rapid evolutionary adaptation and perhaps very different maps. In the future it could also be interesting to evolve levels based on multiple parents, instead of simply selecting one. Additionally, all votes could have an influence on the evolutionary progress instead of a simple winner-takes-all solution. An important future challenge is to extend the current local networking approach to a larger user base through online play. Not only could this garner different results due to the lack of physical presence with other people, but could also provide a substantially larger data set for further analysis. The lineages of maps evolved in this paper were quite shallow, with the longest lineage encompassing six generations. Playing online could allow for more generations than were possible during local play. Here evolution also has to deal with a potentially changing group of players with very diverse skills and changing preferences from round to round. VII. CONCLUSION We presented a novel approach to create multiplayer FPS maps using interactive evolution and procedural content generation, which adapts quickly to the preferences of a group of players. By rating the levels using simple votes, a group of players can rank the levels, and collaboratively evolve maps based on qualities they prefer. Across a range of skill levels, almost all players reported the levels were of higher than average quality and increased in quality as they played the game. The evolved levels matched the players’ preferences closely and most players expressed enjoyment with the game in general. In the future, an online version of the presented approach could produce a continuous stream of novel and distinct maps for a wide range of different players.  J. Togelius, G. Yannakakis, K. O. Stanley, and C. Browne, “Search-based procedural content generation,” in Proceedings of the 2nd European event on Bio-inspired Algorithms in Games (EvoGAMES 2010). New York: NY: Springer, 2010.  J. Togelius, A. J. Champandard, P. L. Lanzi, M. Mateas, A. Paiva, M. Preuss, and K. O. Stanley, “Procedural Content Generation: Goals, Challenges and Actionable Steps,” in Artificial and Computational Intelligence in Games, ser. Dagstuhl Follow-Ups, S. M. Lucas, M. Mateas, M. Preuss, P. Spronck, and J. Togelius, Eds. Dagstuhl, Germany: Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, 2013, vol. 6, pp. 61–75.  J. Togelius, G. N. Yannakakis, K. O. Stanley, and C. Browne, “Searchbased procedural content generation: A taxonomy and survey,” IEEE Transactions on Computational Intelligence and AI in Games, vol. 3, no. 3, pp. 172–186, 2011.  J. Juul, Half-real: Video games between real rules and fictional worlds. MIT press, 2011.  M. Hendrikx, S. Meijer, J. Van Der Velden, and A. Iosup, “Procedural content generation for games: A survey,” ACM Transactions on Multimedia Computing, Communications, and Applications (TOMCCAP), vol. 9, no. 1, p. 1, 2013.  H. Takagi, “Interactive evolutionary computation: Fusion of the capacities of EC optimization and human evaluation,” Proceedings of the IEEE, vol. 89, no. 9, pp. 1275–1296, 2001.  K. O. Stanley, B. D. Bryant, and R. Miikkulainen, “Real-time neuroevolution in the NERO video game,” IEEE Transactions on Evolutionary Computation, vol. 9, no. 6, pp. 653–668, December 2005.  E. J. Hastings, R. K. Guha, and K. O. Stanley, “Automatic content generation in the galactic arms race video game,” IEEE Transactions on Computational Intelligence and AI in Games, vol. 1, no. 4, pp. 245– 263, 2009.  P. Avery, J. Togelius, E. Alistar, and R. van Leeuwen, “Computational intelligence and tower defence games,” in Evolutionary Computation (CEC), 2011 IEEE Congress on. IEEE, 2011, pp. 1084–1091.  N. Shaker, G. N. Yannakakis, J. Togelius, M. Nicolau, and M. O’Neill, “Evolving personalized content for Super Mario Bros using grammatical evolution.” in Proceedings of the Artificial Intelligence and Interactive Digital Entertainment Conference (AIIDE 2012). Menlo Park, CA: AAAI Press, 2012.  J. Togelius and J. Schmidhuber, “An experiment in automatic game design,” in Computational Intelligence and Games, 2008. CIG’08. IEEE Symposium On. IEEE, 2008, pp. 111–118.  S. Risi, J. Lehman, D. B. D’Ambrosio, R. Hall, and K. O. Stanley, “Combining search-based procedural content generation and social gaming in the petalz video game,” in Proceedings of the Artificial Intelligence and Interactive Digital Entertainment Conference (AIIDE 2012). Menlo Park, CA: AAAI Press, 2012.  S. Risi, J. Lehman, D. D’Ambrosio, R. Hall, and K. Stanley, “Petalz: Search-based procedural content generation for the casual gamer,” IEEE Transactions on Computational Intelligence and AI in Games (TCIAIG), to appear.  L. Cardamone, G. N. Yannakakis, J. Togelius, and P. L. Lanzi, “Evolving interesting maps for a first person shooter,” in Applications of Evolutionary Computation. Springer, 2011, pp. 63–72.  L. Cardamone, D. Loiacono, and P. L. Lanzi, “Interactive evolution for the procedural generation of tracks in a high-end racing game,” in Proceedings of the 13th annual conference on Genetic and evolutionary computation. ACM, 2011, pp. 395–402.  D. W. Croft, “A proposed voting system alternative: Multiple-selection, winner-take-all,” http://alumnus.caltech.edu/ croft/research/government/approval/voting.html, 1997.  O. Delalleau, E. Contal, E. Thibodeau-Laufer, R. Ferrari, Y. Bengio, and F. Zhang, “Beyond skill rating: Advanced matchmaking in ghost recon online,” Computational Intelligence and AI in Games, IEEE Transactions on, vol. 4, no. 3, pp. 167–177, Sept 2012. Source: sebastianrisi.com/wp-content/uploads/olsted_cec15.pdf The full 94 page thesis is attached! Thesis level generation.pdf Thank you again to the authors - Peter Thorup Ølsted, Sebastian Risi, and Benjamin Ma. Their Contact information is below. Follow Benjamin Email: firstname.lastname@example.org Linkedin: https://www.linkedin.com/in/benjaminmadk/ Follow Peter Linkedin: https://www.linkedin.com/in/peterolsted/ Follow Sebastian Website: http://sebastianrisi.com/ Linkedin: https://www.linkedin.com/in/sebastian-risi-374a2960/ 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://discord.gg/RqEy7rg
The story behind Dust 2 - the map that was never meant to happen and at best, I thought, would be a foolish attempt to repeat the success of Dust. I gave it a go anyway.IntroductionDespite the success and overwhelming popularity of Dust, the thought of making a sequel took a long time to cross my mind. Although considered by some to be it’s spiritual successor, Cobble failed to find the same audience, and there was clear demand for a ‘real’ sequel. Dust 2 didn’t arrive until March 2001 - nearly 2 years after the original.It was never going to be easy creating a successor to the most-played FPS map in the world. Even with the benefit of the same texture set, an established theme and innumerable number of salivating CS players, it was an incredibly daunting task. I didn’t want to call it “Dust 2” for this very reason. Instead, on the basis that the third installment of any movie trilogy is typically never as good as the first one, I decided to call it “Dust 3”, and hoped no-one would notice. My assumption was that everyone would just carry on playing the original.So, I opened up Hammer, and started laying out “Dust 3”.Sticking to a ThemeFirst things first, I had to ensure that this new map had everything in common with Dust, without actually being Dust. I had to identify the elements that defined a Dust map.The ArchesPerhaps the most iconic aspect of Dust are the arches that separate main gameplay areas. Aesthetically they neatly compartmentalise the map, framing entrances and exits between areas and helping players create a mental picture of the layout. From a gameplay perspective, they produce tight choke-points between objectives, and block out unwanted lines-of-sight. Consider how Dust would have looked without the arches: Lose the arches and you get a deathmatch arena It’s worth reading the original Making of Dust if you haven’t already, as you’ll see the arches (amongst many other elements) were lifted directly from Team Fortress 2.The RoadThe stone roads through Dust were like arteries, giving players clear paths to follow towards the main objective areas. The sequel would do the same, connecting spawn points to the primary objectives.As an example of the importance of these paths, here’s what Dust would have looked like without them: Where we're going, we really do need 'roads' The TrimThe much-abused ‘trim’ along all the walls and ceilings of Dust was perhaps the single element that gave the world a hint of relief and purpose, and helped separate distinct geometric elements. It was incredibly important in a world that was almost otherwise entirely made of the same colour stone.I therefore tried to use the trim very carefully, only exactly where needed, and not just as filler. I didn’t want to repeat the mistake of many Dust-alikes where it had been peppered everywhere it fitted, flooding the visual cortex of players with the excessive complexity. Neither did I want to under-employ it, and end up with a world looking flat and barren.I tried to formalise the rules I’d employed. The trim would never appear on a floor or ceiling, or anywhere a player could stand on it. It would never be striped or tiled vertically across a surface. Finally, for any given flat wall, it would never appear more than twice (e.g. at the top, and at the bottom, but never in the middle as well.)The SunThis was perhaps the element of Dust that underwent the most tweaking - every BETA release of Counter-Strike saw it moved ever so slightly, lengthening the shadows each time. It was key to making Dust distinct amongst the other maps in rotation, and keeping it accessible and pleasant to play in. I considered giving the sequel a night setting, but in doing so would have removed a vital element of the Dust theme. The best I could do was make it exactly the same.The DesignThis new Dust had to bear resemblance to the original beyond the texture set and sunlight. It had to copy important design elements that players had become accustomed to: the ‘Dust doors’, simple structures, ramps, crates and arbitrarily raised concrete areas. In fact, I’d have to copy some areas nearly verbatim to ensure the lineage was present.At the same time, while trying to differentiate the sequel from the original, I’d have to be conservative about any new elements I was introducing. These came in the form of the half-spiral staircase, and the rock face adjoining the two bomb spot areas.There were also two distinct boxes that Dust 3 needed to tick - a place for close-quarters battles, and a place for long, drawn-out AWP fights. Dust had the central corridor and the underpass to fulfill these requirements, and I’d have to create something similar in the sequel to cater for both types of player.It was a lot to juggle.Keeping It SimpleOf course, the most important element that would make or break the sequel was the overall map layout. It had to be Dust-ish, without being Dust, different enough to give players a fresh challenge, but maintaining the balance and pace of the original.I had already spent a long time trying to work out what vital layout ingredients had Dust tick, and reached the conclusion that the simplicity and concise connectivity were key. In it’s most basic form, Dust was little more than a figure-of-eight that had grown a pair of arms and legs, centralising the battles but providing tactical wiggle room.To maximise the sequel’s chances, to make it feel like Dust and play as well as Dust, I’d have to adopt this same structure.Starting OutUnusually, I opted to draw out some doodles, rather than just diving in as I typically would. This sequel was important - it deserved careful, considered, detailed and thorough planning, a long and arduous process that would eventually span literally minutes.One of the most peculiar decisions I took at this stage was to add rock to the Dust theme. The textures had always been there, but I had never used them. It was a (miniscule) risk to adopt them now, knowing the challenges of creating believable rockery with the Half-Life engine, but I took it anyway. I needn’t have worried.The Early Dust 3It took a couple of days to convert the paper design into a playable map, although thankfully was a relatively straightforward process. Through habit, I strayed a bit from the paper designs, but maintained the overall layout that I intended, correcting the scale as I went along.The biggest problem was dealing the relative proportions of gameplay areas. I had inadvertently built the map and filled in the details in such a way that I was now hitting the very edge of the permitted space allowed by Worldcraft. But, rather than just moving the entire map a few thousand units in the opposite direction, I stuck with it, and that’s how the Terrorist spawn area ended up so long in the final revision.AlphaThe alpha version of Dust 3 was pretty close to the paper design, but lacked any character. While it was clearly a Dust map, and had both old and new Dust elements, it was far from being finished. Much like Dust, Dust 2 briefly had a cavern You can see in the shots below that the area I was most unhappy about was the second bomb spot. It only had a couple of entrances and a few crates for cover (just like the original), but clearly needed something more. The road leading from it was also a straightforward junction. All these elements were clearly derived from Dust, but detrimentally so.Around this time I invited Gearbox’s Brian Martel to offer some feedback and advice. He suggested adding arrows pointing toward bomb locations to support the existing floor markings, features that would radically improve the accessibility of the map (and were later introduced into the original Dust and indeed all other official maps.) Bomb site B Bomb site B BetaHeading to beta, I massaged the bomb site with Dust’s bomb site B in mind, adding a raised platform and shuffling more crates in to break the space up and offer more gameplay opportunities.In the process, I managed to find a way to open it up by creating a hole in the wall connecting it to the junction to bomb site A. I considered this risky - Dust had no such elements, and I wasn’t sure quite how it would look or indeed play, but it ‘felt’ right, and the objective became a far more comfortable area to navigate. I pictured how much fun I’d have armed with a Steyr Scout perched as lookout for enemies trying to breach the gates.I also took some liberties with the crates, which were sitting nervously at awkward angles, as if the laws of physics had tumbled them around a little. Again, I was wary that this was a break from the rigid, grid-like nature of Dust’s crate arrangements, such was my concern that such minor elements had been what made Dust a success. While primitive by today's standards, I was still unsure about introducing irregular shapes and a rounded staircase to the Dust theme The staircase was also unnerving. Dust never had stairs of more than a couple of steps, and this map was set to have a half-circular staircase, and in a tight area too. However, I needed some passage between those two areas, and the staircase seemed to fit and provide some interesting conflict.Despite these changes, this map had some familiar elements too. In fact, some elements were ripped nearly verbatim from the original. Dust 2's Terrorist spawn echoes the CT spawn in Dust The ramp pictured above always seemed particularly ‘Dusty’ to me, perhaps because it harked back to the TF2 screenshots that inspired Dust. The CT-side entrance to the underpass in Dust 2 bears similiarities to the T-side entrance to the underpass in Dust Again, notice the similarity - two ramps which both head down into darkness. In Dust 3, the T’s would have started at the higher end of the ramp. This later changed to the CT’s in the underpass in Dust 2.ReleaseThis had all been happening in relative secrecy. I had been intentionally keeping it quiet, not wanting to raise expectations, assuming that once it launched on a new website called GameHelper that would be the end of it. I was convinced that compared to Dust, “Dust 3” would be a failure, despite my efforts.Alas, it was not to be. Jess insisted it became part of the official Counter-Strike rotation, except under the far more sensible name of “Dust 2”. As with Dust, Jess was vital to getting the final balance of the map just right, suggesting new spawn and bomb locations.Dust 2 was released in March 2001, as part of Counter-Strike 1.1. Unlike Dust, it received no further layout tweaks after that. Dust 2's overview image from CS 1.6 Just like Dust, Dust 2 excused itself from my pessimism and became incredibly popular, not just on public servers, but in clan matches too, which Dust had become ill-suited for. Dust 2 later also stole the “most-played map” crown, sharing it only occasionally with Aztec as Dust fell down the charts to newer and better maps. I had never expected Dust 2 to compete with Dust for longer than a few weeks, but like Dust, “Dust 2 24⁄7” servers sprang up everywhere and it’s popularity meant it earned places in later versions and ports of Counter-Strike.Counter-Strike: Condition ZeroLike Dust 1, this version of Dust 2 shares much in common with the original, and is largely based on the original brushwork. The map is notably more vivid and strong in its appearance, with an overall more colourful appearance helped by the additional detail. A few changes have been sneaked in, such as crate placement around bomb sites, but otherwise the map serves as a nicer updated version of the original. Dust 2's received a fresh lick of paint in Counter-Strike: Condition Zero This version was primarily worked on by Ritual, although some finishing touches were added by Valve just before release of the game.Counter-Strike: SourceThis Dust featured a whole host of improvements, from the improved skybox (it really does feel like the middle of a desert now), improved building structures, additional detail, village clutter, as well as slight changes in the layout of the bomb sites to improve the game. Dust in CS 1.6 vs CS:Source From the overview above it’s clear that there were a number of small changes to map proportions versus the one that shipped in CS 1.1. Various passageways have been widened and made more accessible, while others have been lengthened or squared off to improve gameplay and rendering performance. The additional detail also cuts of some lines-of-sight and adds cover where there was none before, but otherwise it’s reasonably faithful to the original. Dust 2's overhaul in Counter-Strike: Source This renovation of Dust 2 was performed by Valve following the renovation of the original Dust.Counter-Strike: Global OffensiveFar and away the most beautiful version of the map ever created courtesy of Valve’s crack team of artists and designers. You can almost feel the breeze brushing around these parts This version was developed by Valve and Hidden Path Entertainment and evidently based on the proportions set by the CS:S version of the map (many CS:S assets can be seen around the map, albeit in updated forms). It’s absolutely stunning.ElsewhereDust 2 has also made appearances in other games, courtesy of the modding community. One of my favourites is the Dust 2 conversion for Far Cry 3, showing the mapping process from start to finish: There’s also the obligatory Minecraft version.ThanksAs with Dust, none of this would have been possible without the help of Joe Markert of GameHelper, Jess Cliffe, Minh Le, Chris Ashton, Brian Martel, Richard Gray, Kristen Perry, Ido Magal, and all sorts of other people.Also, of course, ultimately I have to thank Valve Software for the idea I stole in the first place… erm, twice.Source: https://www.johnsto.co.uk/design/making-dust2/Follow DaveWebsite: https://www.johnsto.co.uk/Twitter: https://twitter.com/johnsto*This article has been posted with the permission of the author, and in accordance with the Creative Commons Attribution-ShareAlike 3.0 Unported License
For a long while Dust was the world's most-played Counter-Strike map and it's still the one for which I am best known. Yet few players realise it was the product of thievery and luck... For many FPS players Dust - and the later Dust 2 - are the quintessential Counter-Strike maps. They’ve been featured in nearly every major Counter-Strike tournament, and been responsible for countless millions virtual deaths, bomb detonations and defusals. But these maps actually owe their existence to Team Fortress 2 - a game that was released eight years after Dust became a staple of the Counter-Strike map rotation. Time Travelling It started in the summer of 1999, Suffolk, England. I was 16 years old, recuperating from end-of-year exams and enjoying my newfound freedom from school work. Half-Life was only a few months old, yet was scooping up more ‘Game of the Year’ awards than there were game magazines, leaving gamers desperate to know what Valve Software were going to make next. Thankfully, news broke that Valve had hired the team behind ‘Team Fortress’, a free mod for Quake that added class-based team multiplayer to the game. Like any responsible teenager, I’d spent more hours sat staring into a screen zooming around dodging rockets, slinging grenades and capturing the flag than I had with my head stuck in schoolwork, much to the chagrin of my parents. Their next project? A sequel, excitingly titled ‘Team Fortress 2’. It seemed that whilst I had been busy ambushing my future educational prospects, behind closed doors Valve had been hammering away at updating and upgrading Team Fortress for a new generation of hardware. News of Team Fortress 2 was rare and sporadic, but occasionally a tidbit here or a screenshot there would nervously peer out to an excited but nervous audience of TF fans. Before too long, a handful of screenshots started their steady journey around the gaming websites of the late nineties. Two particular screenshots leapt out at me: Two early screenshots of Team Fortress 2 The seed had been sown. Meanwhile, a new Half-Life modification known as ‘Counter-Strike’ had been picking up a steady stream of players. In the autumn of 1999, Minh ‘gooseman’ Le and Jess Cliffe released its second beta - and it supplanted Team Fortress to become my new addiction. It came with a texture pack of urban textures (‘cstrike.wad’) that, upon discovery, I set about making a map with - this became ‘cs_tire’, a hostage rescue map set in (of all places) a retirement home. Surprisingly, this map was deemed good enough to be included in the third beta release of Counter-Strike, and Jess subsequently asked me if I’d be interested in making a map for the fourth beta. He was very keen to hook me up with their texture artist to help me make something absolutely and completely original. Jess introduced me to artist Chris ‘MacMan’ Ashton - the same artist behind the urban texture set used in my retirement home map - and we got to work creating a new, totally original Counter-Strike map. Unfortunately it was too late to save me from TF2’s influence and I asked for these instead: Team Fortress 2 screenshots were used to create a core texture set Undeterred by my complete lack of originality, Chris quickly got back to me with beautiful lookalikes. While not exact replicas, I selfishly became completely infatuated with them, just like I had the screenshots they were based on . I quickly bundled them all together into my own texture pack and called it “cs_dest.wad” - shorthand for “Destiny”. With these TF2-alike textures I could finally make a map and pretend I was playing Team Fortress 2, but something was wrong. I felt guilt - TF2 wasn’t even out yet and I was already trying to sap all the effort Valve had been putting into it. It was akin to snatching a duckling from under its mothers beak. “But surely”, I thought, “Valve wouldn’t mind one me making one small map for one small mod for their one and only published game? A map that maybe only a handful of people would ever play?” I marched on. Copy and Paste Starting the map was the easy bit - the first area boasted a long road flanked by buildings, leading to an archway and a wall dividing it in two, just like I’d seen in the screenshots. I decorated every building and wall with ornate trims along the top or bottom, again aping TF2, as I tried my hardest to evoke the same sense of place, desolation, and scale. These features would go on to define the underlying architectural style of Dust. My effort wasn’t quite identical to the map featured in those coveted TF2 screenshots, but it was close enough, and - somewhat more importantly - it was a start. The arched doorways became a hallmark of the Dust theme - a Dust map is simply not Dust without at least two or three arches dividing the map into distinct zones. Creating the first one was at the time a great test of my technical mapping ability, and I struggled for a little while before landing on a technique that worked. My design eschewed the Reuleaux triangle shape of the TF2 arches for a simpler semi-circle, partly because it was simpler, but primarily to ease player passage through them. I extruded the arches from their adjoining wall - lifted straight from the screenshots. The first incarnation of what became the CT spawn I considered against copying the screenshots verbatim for fear of upsetting Valve, and so started guessing how the rest of the area should look. I’d already created a raised platform, and had decided that this could be the area that the Counter-Terrorist team would spawn in at the start of the match. This necessitated defensive measures to protect their spawn area, so I made some windows: The view from inside a building next to the CT spawn Not only did they look hideous, but the windows didn’t give the defensively-advantageous views I wanted the CT team to have. Nor did they fit with the intended gameplay. I didn’t want to encourage the CTs to hold back, and removed them - although in all honestly, at this point I really didn’t know where the map was going. Under the Influence Side-by-side, the TF2 ‘influence’ is plain to see: Side-by-side, the influence of TF2 on the design of the CT spawn area is apparent TF directly influenced building placement and the design of the arches In many respects, the TF2 screenshot looks nicer to me - smoother and softer than the harsh edges of the Dust buildings. I was far more comfortable working with standard geometric shapes, 90 degree corners and 45 degree angles, which is why Dust looks far boxier in comparison to the TF2 screenshot it was based on. That was the easy part done - after all, Valve had already created this much of the map for me and all I’d had to do was copy it. But what I had wasn’t much - it was barely enough for a one-on-one deathmatch, let alone two teams of eight players gunning it out. Worse still, there were no more screenshots to use for ‘inspiration’ - I had to make the rest of the map off my own back and imagination. Extrapolation Having nailed down the design of the first area, producing the rest of the map was merely a case of extrapolating it into a complete, playable environment. However this was much easier said than done - the next section of the map proved rather more challenging. I had created a T-junction out of the CT spawn, but struggled to know what to do with it. My past mapping experience was mostly creating tight interiors rather than not vast exteriors, and so I was feeling very lost. Desperate, I shoe-horned a bend in the road leading to a downward slope, and at the end of it - an underground cavern. The underpass originally descended into a vast underground facility, but this was scrapped the moment I played it It didn’t work, of course. While the CT spawn area was light and airy, this giant room was gloomy, boxy and felt dead compared to the sunny exterior I’d already made. Observing it also lacked any gameplay potential, I swiftly deleted it. Dust would be an outdoor map. I was still stuck. It’s at times like these where working without an initial design can prove extremely difficult. You look at what you’ve got, and struggle to see where to take it, knowing that a step in one direction is a step away from a solution in another direction - and you don’t know which will turn out better. It can be very tough and incredibly tempting to just scrap everything and start again. I’d made all my previous maps one room at a time, making it up as I go along with precious little pre-planning, and they had gone reasonably well. I had to hope I could do the same again. Mercifully, that’s exactly what happened. The Terrorist spawn area, and shallow decline into the underpass Within just a few hours - and seemingly out of nowhere - the Terrorist spawn area was complete. I was far happier with this side of the map, perhaps a product of becoming comfortable with the visual and architectural style. The shallow decline into the underpass is perhaps one of my favourite aspects, both aesthetically and as a player who spent many hours armed with a Steyr Scout at the crest popping off opponents’ heads. At one point I planned an alleyway from the Terrorist side of the underpass that fed around to the CT ‘sniper nest’, but this path seemed like it would be too long, too linear, and simply too dull. I just blocked it up with crates instead, still visible in the original version of the map (and the screenshot above.) Dust’s central hallway was pivotal in tying all these pieces together. Unfortunately, I can recollect very little about its creation, bar my explicit efforts to ensure players couldn’t see all the way through it from one end to the other. Every crate found in the intersection was strategically positioned to cut off lines-of-sight and improve performance. It was in this corridor that each team would typically meet, and so it needed to be fair, and balanced, with a slight defensive bias. The central corridor, Terrorists approached from the top, Counter-Terrorists from the bottom. Note the stack of crates opposite the doorway in the bottom-right corner blocking the long sightline In retrospect, it’s clear the upturned ’T’ shape of this corridor - which gave the CT team two points from which to defend against the single Terrorist entrance point - played an important role pacing each team. A good CT team would hold steady in these locations, forcing Terrorists to check both corners before advancing. However, the Terrorist team had a similar advantage if CT’s became over-confident and tried advancing too far. Getting this balance of opportunity right came down to timing. The aim was to ensure both teams caught first sight of each other in this corridor. Knowing that most players will start running the second the match begins, I did the same, timing how long it took to go from each team’s spawn area to the central corridor. By making sure each team had exactly the same distance to run I could dictate exactly where first contact would be most likely to happen. Bomb Planted Despite the map layout being largely complete, I’d paid very little attention to the core gameplay. Dust would be one of the very first ‘Bomb Defusal’ maps, a new gmetype that was due to be introduced at the same time as the map itself (all previous CS maps had featured hostage rescue.) No one had played a Defusal map before - least of all me - and so I had to rely on guesswork and logic to place the spawns and bomb locations. Bomb Spot A was easy to place - the courtyard area had no purpose otherwise - but Bomb Spot B proved more difficult. I thought about putting it the underpass. This suited better - it was equidistant between the two spawns, and I thought offered a reasonable amount of cover. So it went there. Bomb location decided, I zipped up the map and fired it towards Cliffe for the first round of playtesting. He immediately suggested that the bomb spot below the underpass should be moved directly in the CT spawn - a change that was undoubtedly crucial to the map’s success. The problem was I’d been treating this brand-new ‘Defusal’ gametype as if it was one I knew already - Capture the Flag - except in this CTF mode the flag (the bomb) started at the Terrorist spawn. But Defusal wasn’t Capture the Flag. In fact, it was so utterly different that hardly a comparison could be drawn. Placing the bomb in the CT spawn hadn’t even crossed my mind. I made the change, and sent it back for playtests. Playtesting is an important stage of any map’s development cycle. While thoughtful logic and engineering are incredibly important to help ensure a map’s success, player feedback is critical. There’s little way of knowing exactly how a map will play when faced with real people. It’s playtests that uncover deep and subtle-but-damaging flaws that need fixing before release - if the map is even fit to be released at all. The map overview from CS 1.6 I didn’t get to play in the playtests (by virtue of being in a different timezone) but I heard that they went well enough to be included in BETA 4. To have one map (‘cs_tire’) already in the official map rotation was great, but to have two? The pressure was mounting. What if it didn’t live up to people’s expectations? Would people even take to this new ‘Bomb Defusal’ mode? What if players didn’t like the sunny golden demeanor of Dust, and really did prefer dark, gritty urban maps? A few days later, on the 5th November of 1999 - a Friday - I got my answer. BETA 4 was released as I slept. Saturday morning arrived, and I - skipping breakfast - rushed to download the new beta, just like everyone else had done hours before. There were already hundreds of servers and on them thousands of people were already planting and defusing bombs on the map I’d designed, and I’d not even got to play it myself yet. It seemed as though Bomb Defusal mode was a hit, and thousands of players were already enjoying the change of pace from hostage rescue maps. But how about Dust? Well, this was the day that the first “Dust 24/7” server appeared… …and players seemed to like it. Getting BETA Dust underwent changes in almost every subsequent release of CS during the BETA phase. These changes were frequently somewhat speculative, more often they were aesthetic, and sometimes they changed the game play entirely. BETA 4 Comparing the first version of Dust to CS 1.6’s shows the major differences that were made in its lifetime. BETA 4 Dust had far fewer crates and cover than in CS 1.6 - all added to help balance the map and embellish defensive/offensive strategies. Aesthetically, CS 1.6’s Dust is also far cleaner and warmer, having benefited from a custom skybox and tweaked sunlight. Between CS BETA 4 and CS 1.6 the sun shifted slightly, elongating the shadows and upping the contrast to match the new skybox Between CS BETA 4 and CS 1.6 the Terrorist spawn also had a minor facelift with additional graffiti. The source of the sunlight and the shadows it created helped draw Terrorist players towards the bomb spots BETA 5 The BETA 5 version of Dust consisted of both aesthetic and gameplay changes. One seemingly small gameplay change was introduced in the form of a crack in the wall of the CT sniper nest overlooking the underpass. The intention was to expose CT snipers, making it easier for Terrorists to advance through the underpass. I reinforced this principle by adding more crates in the underpass as cover, strategically placed to let them get close enough to toss a grenade into the sniper nest. The underpass in BETA 5 had a distinct CT bias, with a crack in the wall and very little cover making it hard for Terrorists to get through The crack in the wall backfired. Rather than hinder CT snipers it had helped them by offering a wider, unobscured view of Terrorists entering the underpass. Miraculously, the full wall was restored in BETA 6. BETA 6.1 and 6.5 BETA 6.1 contained a small change to spawns that had big consequences. I thought the map had become unbalanced in the favour of the Terrorist team, and wanted to find a way to address this advantage. My fix involved moving the CT spawns forward by a few metres to push back the first line of contact between the two teams. The exact placement of Dust’s player spawns had always been crucial in ensuring balance, so I knew that tweaking them could have large repercussions. However, this was one tweak too far - once 6.1 was released it was clear the change the balance had become worse, not better. What happened? The change had made it easier for CTs to hold down the hallway, and harder for the Terrorists to rush the bomb site - all exactly as intended. However, the balance was now slightly too far in the CTs favour, and while some players welcomed this change, it was an overall worse experience for most. In BETA 6.5 the CT spawns were reverted back to their original positions. (BETA 6.5 also introduced my third Counter-Strike map, ‘de_cbble’. It was very nearly a castle.) Retail 1.0 In April 2000, Valve bought Counter-Strike and secured the right to include Dust in a physical, boxed retail version of the game. It was hard to believe this small map I’d made in my spare time less than a year before would be appearing on store shelves. Yet, on the 1st November 2000 - days before Dust turned one-year-old - that’s where it was. I was now 17, and Dust was now my first published work. (A few months later my fourth CS map - the inventively titled ‘de_dust2’ - was added in CS 1.1.) Rejected Ideas Dust didn’t see any further changes after 1.0. The map was about as good as I could make it without the risk of alienating players who were fans of the map, and I really didn’t want to rock the boat. However, that’s not to say I didn’t toy with a few ideas… The major change that I almost made at CS 1.1 time would have changed the dynamics of the entire map destroyed many proven strategies. I thought a new route directly from the underpass to the very centre of the hallway would help Terrorists form a firmer front-line, and encourage a more defensive strategy. Rejected: a staircase joining the underpass to the central hallway In retrospect, I think it would have just become the fastest route for Terrorists to reach the underpass, undermining and deprecating a large area of the map in the process. It would have removed one of the dynamics that made the underpass so fun. (Note this is not the same as the staircase added to Dust in CS:GO, which connects the platform above the underpass directly to the bottom. I believe the CS:GO solution is far better suited to Dust than my original plan was.) 24/7 Dust was once the most-played FPS map in the world, both in terms of the number of concurrent players, and the amount of time those players spent in the map. There were thousands of “Dust 24/7” servers, and the map became particularly popular amongst newbies, despite falling out of favour from clan matches. Dust turned out to be the perfect place for new players to learn the rules of the game, without being distracted by map complexity. There is no way to know how well the map would have done if some of the changes mentioned in this article remained - for example, the bomb site in the underpass, the sniper house, or the stairs between the underpass and the hallway. I expect they wouldn’t have worked in the maps favour. Ultimately, it’s hard for me to claim I knew what I was doing as I pieced Dust together. I attribute its success more to incredible luck and lack of imagination more than any skill I possess. If anything, I learnt more from Dust post-release (and in writing up these memories!) than I knew when I was making it. Counter-Strike: Condition Zero In March 2004 Valve released Condition Zero, an updated version of Counter-Strike that included a single-player mode and updated versions of all the popular maps from the main game. Its version of Dust shared much in common with the original, being largely based on the original brushwork. The map notably featured more pronounced structural detail supported by an expanded and more colourful palette. Dust got a fresh lick of paint in Counter-Strike: Condition Zero This version of the map was the product of Ritual, although some finishing touches were added by Valve just before release of the game. The Levelord played a hand in the renovation. Counter-Strike: Source Dust in CS 1.6 vs CS:Source In November 2004 - mere months after the release of Condition Zero - Valve released Counter-Strike: Source, a completely refreshed and revamped version of Counter-Strike based on the Source engine. Counter-Strike: Source introduced the biggest changes to Dust in its history, with more realistic proportions and the introduction of physics objects This renovation of Dust was done at Valve by Kristen Perry and Ido Magal who were given the unenviable job of determining appropriate architectural references for Dust based upon the Condition Zero version. I think they nailed the look completely - maintaining the golden tones everyone was used to, embellishing the few details that were there and giving Dust the kind of ambience that it had always lacked. My reaction when I first saw what they had done was nothing short of complete astonishment and amazement. I was proud of what Dust had become and ever grateful to those who had helped get it there. Counter-Strike: Global Offensive The CS:S version of Dust caused my jaw to drop, but the iteration in CS:GO floored me. Easily the most detailed, intricate and life-like version of Dust ever created This version was developed by Valve and Hidden Path Entertainment and evidently based on the proportions set by the CS:S version of the map (many CS:S assets can be seen around the map, albeit in updated forms). This version heralded the most major layout changes to the map since the original release, featuring a bridge across CT side of the underpass, and a staircase by the underpass, refreshing Dust for competitive play and bringing it in line with more recent maps. The underpass has a side passage leading directly to the central corridor At a glance these changes bear a resemblance to one of my “rejected ideas” above, but only in concept. The underpass’s linearity always posed a problem due to its length, and Valve clearly agreed that a third exit right underneath the platform was necessary. But unlike my solution, which would have drawn players right into the centre hallway, Valve opted to put the underpass passage on the opposite side, directing players up to the far end of the platform. It’s clearly the better design and one I wish I had thought of when I still had the chance! Meat-Space Dust has also manifested itself in real, physical forms… Dust manifests itself in real life I still don’t know who was responsible for the sand castle, but the real-life crates were by Aram Bartholl, a Berlin-based artist who is also planning to create a life-size Dust replica. And then, of course, there’s Minecraft: Minecraft This Minecraft version of Dust was made by users of the cdg.net forums, who have also been recreating other popular CS maps. In Closing To this day I am still amazed that Dust was as successful as it has been, and I have a hard time believing that I actually created it at all. But, looking back, its success is hardly surprising given those who helped it along the way, from Minh Le and Jess Cliffe’s invitation and support, to Chris Ashton’s painterly skills, the feedback from players, through to Brian Martel, Richard Gray, Kristen Perry, Ido Magal, and a whole plethora of talented behind-the-scenes clever clogs who I’ve never had the pleasure of meeting, but deserve far more credit than I could ever give. Also, of course, ultimately I have to thank Valve Software for the idea I stole in the first place, and without which none of this would have ever happened. I hope they didn’t mind. Source: www.johnsto.co.uk/design/making-dust/ *Note: This article has been posted with the permission of the author, and in accordance with the Creative Commons Attribution-ShareAlike 3.0 Unported License Follow Dave Website: https://www.johnsto.co.uk/ Twitter: https://twitter.com/johnsto 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