Jump to content

Squeebo

Members
  • Content Count

    65
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    Squeebo reacted to Rusk for an article, Effect and Cause - Titanfall 2 Level Breakdown   
    Intro
    Titanfall 2 was one of the best FPS titles of 2016, featuring a very strong single-player campaign with interesting combat and puzzle gameplay for both players and their Titan. Additionally, each level featured its own special twist: "Effect and Cause", for example, presents players with a memorable time-traveling mechanic.
    The time-travel mechanics of "Effects and Cause" serve couple of purposes, influencing not only the way players traverse the environment and its associated obstacles, but also how they fight through the level's combat scenarios. Two different time periods are a threat to the player, so the designers decided to allow players to see where the enemies from the past are located.
    Once you move from past to the present, enemies leave a small blue particle in the place where they had been standing. Although the effect lasts no longer than two seconds, it’s enough to help players plan their next move. This twist on encounters makes them much more interesting and dynamic.
     

     
    For "Effect and Cause", the developers created distinct enemies archetypes with different engagement distances and attacks for each time period. In the present (a destroyed version of the map) the player deals with robots and wildlife. In the past, players face armed guards in the facility. Eliminating the danger in one reality does not make it disappear in the other, forcing players to think constantly about their position versus the enemies in the different time frames.
    Let’s discuss three selected encounters from "Effects and Cause" in-depth to see how they work in action!
     
    Encounter 01
    The first encounter where players freely use the time-shift mechanic starts shortly after players exit a lab area. Here, enemies are located only in the past, when the facility is operating and functional. This prevents players from becoming overwhelmed with two types of enemies in two different realities within the first big encounter of the level.
     
    Layout

     
    Combat space
    This encounter is set up in two distinct spaces. The first space is a big room with a single entry point in the form of a double door opened by a panel, with combat focused at the far end of the room. The second space is a large corridor with a pocket in the middle and a security room at the end. A panel in the security room must be used in order for the player to progress.
    Both encounter spaces are divided by a time-shift puzzle, the only way to continue onto the next arena. This time-shift puzzle serves as combat gating and also adds variety to encounters that are otherwise only about shooting. The gating also teaches the player that some spaces cannot be traversed in any time period, and that the only solution to the obstacle is to find alternative routes.
     

     
    Enemies
    There are eleven enemies in this encounter: four located in the first room, and seven in the second room. Once you eliminate the two enemies in the first room, the remaining two enemies get into position. The second space has a fixed number of soldiers, with no additional waves. All the soldiers are using guns or rifles. The advantage/challenge to the player in this encounter comes from the number of the enemies, not their abilities.
     

     
    Encounter design
    Once the player enters the first space, they see two soldiers talking to each other. It’s up to player to start the fight and pick their preferred attack method. Once the first two enemies are eliminated, players enter an area with clearly defined architecture and a no-man’s-land inbetween. Players should also see a weapon lying on the desk, a gameplay "carrot" which helps to draw players into the fight. The enemies will hold their positions and try to shoot the player from behind the safety of cover.
    The second area gives players more options, and also allows them to scan the area earlier (both from the first room through the lasers, and also from a vent). The designers ramp up the difficulty here, introducing more enemies into a tighter space.
    With the time-switching mechanics at hand, players can prioritize threats in order to set up their own tactics. It’s clearly up to player how to plan and play this encounter. As there is no threat in the past timeline, players can experiment with going back in time without punishment, ‘escaping’ the combat at any given moment in order to reload, reposition and jump back to the action. This encounter is memorable as it is the first time that players fully use their time switching mechanic, functioning as a safe environment to learn. In other words, it's a skill check and a preparation for what lies ahead...
     
    Encounter 02
    The second encounter worth analysis is much more varied with how it positions enemies throughout the level. It also places enemies in both time periods, serving as a playground for prioritization strategies and other interesting player tactics. This encounter also features more verticality, which helps prevent players from feeling too overwhelmed with enemy forces, while also allowing players to use more of their Titan-piloting skills.
     
    Layout

     
    Combat space
    This encounter is located in a fairly large room with ample verticality. Players enter the space on the upper floor through a single entry point and continue their way onto a balcony, letting players familiarize themselves with the space from above. At the far end of the room, players will spot a staircase going down to the lower level where elevators are located. This area has two big areas of standing cover, accessible on both heights, and a variety of crouch-height cover such as railings, desks and potted plants. This space also has a small side-room allowing further tactical options. This whole area is gated with an elevator door which does not open until the combat encounter is over.
     

     
    Enemies
    This encounter is quite varied in terms of the enemies players face. In the past timeline, players face eleven soldiers: nine regular soldiers and two heavy soldiers with shields. These soldiers come in four groups of two or three each. The solders come with short intervals inbetween each wave, so that the player has time to react and make more intellectual choices.
    In the present, players face three robots appearing almost at once when they walk along the balcony at the top of the space. Once the player goes down, they have to fight four prowlers which appear one after another with a couple of seconds delay between each new spawn.
     

     
    Encounter design
    We start the encounter in the present timeline, with the gate blocked in the past timeline. On the way to the staircase, three enemy robots spawn but do not pose a big threat to players. Once players move down, their attention is drawn to a desk with guns. This helps players to immediately position into a location in front of the elevators.
    Once players shift to the past, enemies start to appear from the elevators. There is not enough cover to fight off all of the attackers, forcing players to prioritize and switch in time to better position themselves for attack. Once players go back into the present, prowler enemies will start to appear, forcing players to continue constant movement.
    This encounter may feel a bit hectic, but it is a good test of both pilot skills and thoughtful time switching. It's the first encounter which forces players to prioritize which enemies they want to deal with first in different time periods. Due to the designer's smart use of the elevators, vents, and robot storage, enemies are brought into the field in an interesting way. But at the same time, enemies are introduced to the player with clear sound and visual cues, so they remain alert to upcoming surprises.
     
    Encounter 03
    The third encounter I want to breakdown is by far the most robust yet. It features different height levels, space divided into two areas, and flanking paths which can be accessed only through certain time periods. It serves as the "final skill check" for all of the pilot abilities and time-shifting gathered thus far in "Effect and Cause".
     
    Layout

     
    Combat space
    This encounter is spread across two areas of vertical space, connected by multiple paths that create nice loops for players to use to their advantage. There is one clear entry point with a wide view of the whole combat space and one exit located in the second area, but the space inbetween offers a great deal of choice in terms of how players can tackle the encounter.
    Playing through the encounter, players will learn that there is a geometry difference between the two different time frames that can be overcome with some of the pilot skills at their disposal. A big catwalk goes around the whole room with additional rooms with guns and ammo on the bottom level, for example. The amount of space available is needed, because the combat space is packed with enemies.
     

     
    Enemies
    In the past, players have to fight twelve soldiers: nine regular soldiers and three heavies with shields, as well as three robots. The enemies are spread out across the whole space of the encounter, but because the areas are connected with each other through multiple paths, the enemies will try to chase and eliminate the player. This means that the encounter feels very dynamic and tense.
    In the present, players face robots: eight prowlers inside, and even more of them outside fighting with BT (the player's Titan). The enemies in the present are hostile to each other, showing players an example of how the enemy AI can actually fighting eachother: information which players can then use to their advantage.
     

     
    Encounter design
    Players enter this area in the past, where they witness a single back-facing enemy, instantly inviting them to perform a takedown. From this point, the encounter is very open to experimentation: the player can either continue in the past and fight a big wave of soldiers coming through the main path (a staircase in the middle), or they can switch to the present, where they will find open flanking paths on both sides of the level. Going with the latter option offers a moment to breathe before prowlers are spawned, but it will also disable an ammo dispenser in the first area, adding consequence to player choices.
    Staying in one place will result in a massive pile-up of enemies in the area, so players are motivated to move around a lot, time shifting when needed. The second area of this encounter is one of the level's biggest in-door combat spaces. If players choose to go into this second area in the past, the encounter will be quite vertical with soldiers located both on the ground and on the upper catwalk. Switching to the present will cause a bigger concentration of enemies on the ground floor.
    Players are given enough space to fully use pilot’s zip-line ability to create shortcuts across the room, accessing the various loops and ammo dispensers needed to create a fair fight despite overwhelming enemy forces. There are very few conditions placed upon this encounter, so players can leave the area and jump into his Titan to deal with different threats at any time. Overall, this encounter serves as a test of everything learned previously, with players having the option to ‘lower’ the difficulty of the encounter using their titan.
     

     
    Conclusion
    The above examples are just a slice of Titanfall 2 gameplay contained within the excellent level "Effects and Cause", but in my opinion clearly shows how this great game was enhanced by its time shifting mechanic. The idea is fairly simple: time-shifting is nothing more than teleportation between two different levels, one layered on top of another, but the strong execution makes for a memorable experience that really stands out in comparison with other shooters. I highly recommend playing "Effects and Cause" as it is both challenging and fun, a level where Titanfall 2's time-shift mechanics comes into focus, providing additional depth to the whole game.
     
    Thanks for reading!
  2. Like
    Squeebo reacted to Radu for an article, Level Design in Max Payne: Roscoe Street Station   
    Level Design in Max Payne: Roscoe Street Station
     
    Max Payne is a third person shooter developed by Remedy Entertainment and published on July 2001. At the time of its release, the game gained critical acclaim for its use of the bullet time mechanic - a special ability that slows down time around the character. Inspired by Hong Kong action films and hard boiled detective novels, the game focuses on intense action sequences and the protagonist's internal struggle as he attempts to avenge his murdered family.
    The game's story is structured under three parts, each containing several chapters. For the purposes of this article, we will take a look at Chapter One: Roscoe Street Station, from the first part of the game, and deconstruct the level progression as well as state design decisions when encountered.
     

                                                                                     1                                                                                                                   2                                                                                                                3
    The level begins with a cutscene of Max riding the subway train towards Roscoe Street Station to meet with his friend Alex. As soon as Max gets off the train, he remarks that “The station was drenched in gloom. Alex was a ghost nowhere to be seen. I’d have to look for him”. Although we aren’t given much information to work with, it’s enough to build a sense of mystery and give the player a goal.
    Taking control over the character, we discover that our main path is blocked (1) and are forced to explore a side area (2) where more narrative is to be revealed. As we burst open the doors of the personnel room, we stumble over the body of a transit police officer (3). Once again, a quick cutscene centers on Max while he delivers his lines and sets the tone accordingly: "Death was in the air at Roscoe Street. I'd have to find Alex fast." At this point, Max pulls out his pistol and we can either return to the starting area or explore the room for hidden ammunition and health. Doing the latter teaches the player that exploration is rewarded through much needed supplies.
    On our way back, we encounter our first two enemies and notice that the main path is no longer blocked. Though, If the player takes his time and waits around the corner before engaging the enemies, bits of story will be delivered by them, explaining their reason for being there or informing on the overall situation. And as trivial as that sounds, it can have a major impact on immersion and believability. Clearly this is something the developers have identified early on and implemented throughout the game. Giving the player the option to advance at his own pace goes a long way and makes for a more dynamic experience. Those who want to rush through the levels can do so. Others that want to explore and listen to bits of story can do that as well. It’s an ideal situation that satisfies both worlds.
     

    4
    After our first encounter, we can proceed through the main path where we immediately find two more enemies. As previously mentioned, we have the option to directly engage in combat or wait for the enemies to reveal additional information. An important thing to make note of is that despite the fact that the gameplay space is tailored around the player’s needs, the environment always feels natural. A good example is this specific bit (4), where the player is now emerging from a set of stairs and can dive on his side towards a nearby mail box for cover.
    When designing a space that is supposed to represent a real life location, it's essential for the level designer to always keep in mind that everything placed in the scene must abide by the real location's logic. Of course, adding something unusual or out of place is a good way to draw the player's attention, but in general we all have expectations of what kind of objects to find in most environments. Meeting those expectations is key to creating a believable game world.
     

                                                                                      5                                                                                                                   6                                                                                                                 7
    Going down the corridor, we hear another enemy, but this time located behind an inaccessible gate (5). Although his placement seems odd, this set-up accomplishes two things. Firstly, it creates an audio cue to draw the player forward. Secondly, it gives the illusion that the environment is much larger than it actually is. It's a simple trick and probably one of the oldest in the level design book, one which the developers have used extensively throughout the game to their advantage. If you find yourself creating a fairly linear level, simply adding a few inaccessible areas is a quick and painless way of providing some visual depth to your environment. As in real life, there are plenty of areas that we cannot access.
    Continuing with the idea of guiding the player, we begin to notice even more ways of doing that. This time our direction is implied through arrow signs in combination with an enemy audio cue (6). And after encountering the said enemy we acquire a new weapon type, the pump action shotgun, as well as discover the Subway Control Room (7). Unable to access it, Max elaborates that “The security panel let off a mocking cackle. I’d need the right code”. Without knowing specifically why we need to gain access, we can nonetheless conclude that opening the Subway Control Room is somehow tied to the level progression in some way. Turning to our immediate left, we begin to descend to a closed station.
     

                                                                                       8                                                                                                                 9                                                                                                                10
    At this point, having also acquired the shotgun, the difficulty starts to increase as we encounter three enemies on our path. Once they have been dealt with, we find ourselves in a fairly elaborate space with two options for exploration:
    Taking the path to our right, we end up in a room (8) designed to replenish the player’s ammunition and health. Going to the back of this room, we locate a corridor leading to a locked grate door. Even though we cannot open it, reaching the end will deliver additional information through the means of dialogue between two enemies situated on the other side. In contrast to previous encounters, this time we have the option to kill our enemies by shooting a nearby propane canister. After dealing with them, Max notes that "The gate was locked. I would need to find another way to get to the tunnel". This gives us a hint as to where we need to go in order to progress with the main goal.
    Opting for the path to our left, towards the end of the station, we locate a personnel room, a bright yellow maintenance train (9) and a small supply room. Checking out the maintenance train, Max states that "The power to the rail had been cut. I'd have to get it back on to get the train moving". Looking to the opposite side of the train, we notice a tunnel blocked by a series of wooden boards. Putting two and two together, we must find a way to power up the maintenance train and crash though the boards to reach the level's final area. Of course, now we realize why we must gain access to the Subway Control Room. Turning our attention away from the train, we open the door to the nearby personnel room. Inside, we find a transit police officer held at gun point by an enemy (10). After killing the thug, the officer informs us that he can access the Subway Control Room and so we begin to backtrack. Having reached the security panel, the officer unlocks the door, but is shot dead by an enemy already on the inside.
     

    11
    Reopening the door, we notice the enemy has retreated to a secondary room. Pursuing him, we encounter 3 additional thugs, totaling 4 enemies, the most we have yet to fight at once. It's important to notice that, as we advance through the level, the number of enemies we encounter at a given point increases, but in a manner that is fluid and balanced. So far, the pattern has been to include single enemy encounters between group encounters. This way, the player doesn't constantly feel overwhelmed and has time to recuperate before a larger fight. 
    After dealing with the enemies, we discover a third smaller room to the back. Inside this room there is an electric panel (11) that controls the subway power lines, a cabinet with health supplies and a series of camera displays. Using the button on the electric panel triggers a green line to rise on it's display, giving the player visual confirmation that power is now back on for that specific line. Additionally, using the nearby camera display will show an image of the bright yellow maintenance train and compel Max to state that "The train lit up like a Christmas tree. The power was back on". 
     

                                                                                           12                                                                                                           13                                                                                                              14
    We then proceed to backtrack to the train. Backtracking again. Sometimes, and especially if overdone, this design decision can become tedious and potentially confuse players. However, when used sparingly in design and with a bit of logic, forcing the player to go back and fourth between parts of the level in order to progress can make the environment seem more connected as a whole. Backtracking can also prove to be a good way of making the most out of a given environment by squeezing as much gameplay as possible.
    Once we have reached the train, we can either immediately operate it or explore the area behind it for ammunition. Manning the wheel (12), the train begins to accelerate and shortly crashes through the wooden barricade. Advancing in the tunnel (13), we encounter 3 enemies and reach the area seen previously from the locked grate door. Our only path to follow now is through a rusty door leading to the next level (14). While we didn't accomplish our primary goal in this level, we still managed to gather information about the situation, be it directly from Max's lines or indirectly from the enemy dialogue. 
     
    Conclusion
     
    Despite it's ever growing age, Max Payne still proves to be relevant even today. Examining how the gameplay unfolds in Roscoe Street Station, we can only conclude that the people at Remedy Entertainment are without a doubt true masters of their craft. And for those passionate about designing single player levels, here are 10 principles that we can learn from them:
     
    Story is revealed in small amounts to keep the player interested for more Exploration is rewarded through useful items Inaccessible areas can give more depth to the environment Players that want to be engrossed in the game world are rewarded with additional information Environments are designed with a certain logic to meet player expectations  Players are guided through subtle visual language or audio cues Progression obstacles are designed to be relevant to the story Intelligent backtracking uses the gameplay space to it's full potential and makes the environment seem more connected Interaction with the environment is reinforced through audio-visual feedback Properly balanced difficulty allows the player moments of rest and doesn't constantly overwhelm with enemies  
  3. Like
    Squeebo reacted to will2k for an article, Optimizing An Open Map in Source Engine   
    An open map?
    Source engine, which is funnily a Quake engine on steroids (a bit of exaggeration but still), inherited the same limitations of its parents in terms of visibility calculations: BSP and PVS. This fact makes Source, as was Quake engine before, more suitable to rooms and hallways separated by portals where the BSP shines in all its glory.
    Inheritably, Source does not like large open maps where the PVS is of considerable size and the over-rendering is a real issue.
    If you work with Source engine, then you already know the importance of optimization in a large, detailed map. Optimization becomes even more imperative when the said map is open.
    What’s an open map? Good question. The word “open” is an umbrella term to denote any map that does not have traditional hallways and corridors that connect indoors to outdoors. The map is mostly large, outdoors with an unbroken skyline; in other words, the same stuff that source engine nightmares are made of in terms of PVS and BSP.
    In a traditional “hallway’d” map with twisted corridors leading to open areas followed by other hallways, and even if you “forgot” to place hints and areaportals, the geometry itself allows the engine to cut visleaves and limit visibility; granted the visleaves’ cuts will be subpar and messy and the PVS will be in excess, but still, the visibility and fps will be relatively under control. A twisted hallway is a remedy to long sight lines after all.
    In an open map, and without hallways and enough geometry to help the engine, the PVS risks to be huge and the whole map could be rendered at once from any point (over-rendering). We are talking here about a severe fps killer and a potential slideshow on a medium to low range computer. Source does not like over-rendering; I repeat, Source does not like over-rendering.
    I believe a screenshot should be welcome at this stage to illustrate an open map. I’ve chosen a nice medium-size map from CSGO to showcase the issue: de_stmarc.

    The shot is taken in Hammer obviously, and you can immediately see that the skybox is one big unbroken body from one edge of the map to the opposite one. This is the classic definition of open map.
    Let’s see this map in 2D view from the side.

    I have highlighted the skybox in blue so you could see the continuous sky body all over the map. Please note that an open map can have varying skybox shapes but I’ve chosen the simple and classic one to showcase my point where it is easier to see and visualize the concept of open map.
    In contrast, a “traditional” map will have several skyboxes, often not connected directly but rather through a system of indoor rooms or hallways, varying in size and shape.
    I will have my map de_forlorn as example here.

    I have also highlighted the skybox in blue and you can easily notice several skyboxes for CT spawn, T spawn, and Mid/bombsites. These skyboxes are not directly connected to each other but the areas related to them are linked on the lower levels through various indoor locations, some vast (like garage, tunnels…) and some small (like lab hallway…).
    If you are not that comfortable with source optimization or feel that certain terms are alien to you, then please read my previous optimization papers and articles before proceeding further in this article (Previous papers can be found here Source Engine Optimization roadmap).
    The necessary tools
    I’m not revealing a secret when I tell you that the same tools used to optimize any map in Source are exactly the same ones used for optimizing an open map. If you were expecting some magical additional tools, I’m sorry to bust your bubble.
    Since the tools are the same (nodraw, func_detail, props, hints, areaportals, occluders…), it is more about how to use them in open maps that makes all the difference.
    So, how to properly optimize an open map? Well, you could always pay me to do so for you (joking…not…maybe…I dunno!!)
    If the above option is off the table, then read on the rest of this article .
    Horizontal hints
    While in a traditional map one might get away without using horizontal hints, it is virtually impossible to skip them (pun intended) in an open map unless you want to witness single digit fps burning your eyes on the screen. They are of utmost importance to negate the "tall visleaves across the map" issue.
    In a traditional map, even if you bypass adding horizontal hints, the damage in fps will mostly be local since the skyboxes are not connected and areas are mostly autonomous in terms of PVS. In case of my map “Forlorn” and referring to the 2D diagram above, if I remove horizontal hints from CT spawn, then only this area will suffer from tall visleaves and over-rendering. Obviously, this is not cool in terms of optimization, but at least the effect will be somehow restricted to this area only.
    In the case of “Stmarc”, you can certainly see that not including horizontal hints will have tall visleaves seen from across the map as the skybox is one unit. The PVS will grow exponentially and the over-rendering will take its toll on the engine.
    Let’s move on to some screenshots and diagrams, shall we.

    This is our glorious open map in side view. The blue lines denote the skybox, the dark grey one is the ground, and the green rectangles represent solid regular world brushes such as building bases for example. The red starfish little-man-with-arms-wide-open is the player. The orange hollow rectangles denote the various visleaves that the engine would probably create in the map (most go from ground level to skybox level and this is what I refer to as “tall visleaf”).
    If you know your optimization, then you certainly remember that BSP relies on “visibility from a region” approach (for a refresher, please consult my papers Demystifying Source Engine Visleaves and Source Engine PVS - A Closer Look. This simply translates to the following: the player is in visleaf A and visleaf A has direct line of sight to visleaves B, C, D, E, F, and G. The PVS for A in this case would be stored as BCDEFG. Once the engine recognizes that the player is in A, and regardless of the exact position in A, it will proceed to render the whole PVS content. Everything in visleaves BCDEFG will be rendered even though the player is at the extreme end of A and has no line of sight to most of this content.
    You can immediately notice the extent of damage you will inflict on your open map if you neglect adding horizontal hints: excess PVS with additional useless content to be rendered at all times.
    Now that we established the importance of these horizontal hints in open maps, the question remains: where shall I put these hints?
    In the diagram above, the most logical places would be on top of the 3 green rectangles.

    We added 3 horizontal hints (H1, H2, H3) on top of the 3 regular brushes in our map (the hint face neatly resting on the top of the regular brush while other faces are textured with “skip”). This will create more visleaves as can be clearly seen in the above diagram, and vvis will take more time to calculate visibility due to the increased number of leaves and portals but this is done for the greater good of humanity your map’s fps.
    Now the player is in visleaf A1 and the PVS is reduced to (sit tight in your chair) A2, A3, A4, B1, B2, C3, C4, D1, E4, F3. On top of the nice result of a greatly reduced PVS (and therefore content to render), keep in mind that leaves A4, B2, C4, D1, E4, and F3 are mostly empty since they are way up touching the skybox.
    Some folks will start complaining and whining: what the hell dude, I don’t have 3 green rectangles in my map; where would I put my hints?? My answer would be: deal with it!!
    Joking aside, open maps will greatly differ in size, shape, geometry, and layout. What you need to do is choose 1 to 5 common height locations in your map where you would implement these hints. Medium maps with mostly uniform building heights can get away with 1 horizontal hint, while complex, large maps with various building heights can do with 4-5 hints.
    If your map has a hill made of displacements that separates 2 parts of the map, then it is also a candidate for horizontal hints. You just need to insert a nodraw regular world brush inside the displacement to be used as support for the horizontal hint (the same technique can be used if you have a big non-enterable hollow building made mostly of func_detail/props/displacements).
    Vertical/corner hints
    These might not come into play as much as their horizontal siblings, however they could see a growing potential use depending on the map’s layout, geometry tightness versus openness.
    I cannot go through all combinations of open maps obviously to show you how to lay vertical and corner hints; what I will do is choose one diagram representing a typical open map scenario with some scattered houses, streets, and surrounding fields. Once you see how I proceed with these hints, it will become a lot easier for you to implement them in your own map regardless of the differing geometry and layout.

    Here’s our typical map viewed from top with grey lines being map borders, green rectangles being houses (solid world brushes), and our tiny red player at the rightmost part of the map. The map has a main street that goes in the middle between houses but the player is not restricted to this path only.
    The diagram below shows how I would proceed with my hints for such setup.

    This is basically what you get when you give a 5-year-old some crayons.
    Seriously though, I just gave each hint a different color so you could discern them on the spot, otherwise it would be hard to tell where each one starts and ends.
    Most of these hints go from one side of the map to the other while going from ground level to skybox top; don’t be afraid of having big hints that cross your entire map.
    Notice that we have both straight vertical hints (shown from above in the diagram obviously) and corner hints; what I did is that I compartmentalized the map so wherever the player is, chances are they will have the least amount of leaves to render in the PVS (this is just a basic hint system and more fine tuning and additions could be done but you get the gist of it).
    To get more details on hint placement, please refer to my paper Hints about Hints - Practical guide on hint brushes placement
    Areaportals
    If your map has enterable buildings, then it is imperative to separate indoors from outdoors using areaportals; this is top priority.
    Make sure to slap an areaportal on each door, doorway, cellar door, window, roof opening, chimney, etc. that leads inside the house in question.
    What about outdoor areaportals? Good call. In an open map without much regular world brushes to maneuver, it could get very tricky to set up an outdoor areaportal system to separate areas. However, you should always strive to have one, even if it is one or two areaportals across the map. The reason is very simple: the view frustum culling effect, which, coupled with hints, will yield the best results in cutting visibility around the map.
    Continuing with our previous diagram, a simple outdoor areaportal system setup could be as follows (top view).

    This setup will make sure that the map is split into 4 areas and whenever you are in one of them as player, the view frustum culling effect will kick in to cull as much detail as possible from the other areas.
    Let me show you the setup from a side view to make it easier to visualize.

    This is the same areaportal that was closest to the player in the top down view diagram but this time viewed from the side. Unlike hints where it’s fine to have one big hint going across the map, for areaportals, it is best to have several smaller ones that tightly follow the contour of the geometry eventually forming one big areaportal system.
    Another possibility for outdoor areaportal system is to have a combination of vertical and horizontal (yes horizontal) areaportals.
    If your map is a village for example with a highly detailed central square where most of the action takes place, a potential system could be made of several vertical areaportals that sit in every entrance to the square from adjacent streets, and a horizontal areaportal that “seals” the area and works as a “roof”.
    For a practical guide on areaportals placement, please check out my article Practical guide on areaportals placement
    Props fade distance
    This is a really, really important tool when optimizing large open maps. In case you got distracted while I was making the announcement, I’ll go again: props fading is definitely vital when tackling open maps optimization.
    What you need to do is to set an aggressive fade distance for all trivial props that do not contribute to gameplay. Players will look closely at how detailed your map is when they check it out solo on the first run; however, when the action starts and the round is underway, adrenaline, focus, and tunnel vision kick in, and all the details become a blur.
    During an intense firefight, players will not notice small props and details up close, let alone at a distance. We need to use this to our advantage to fade props thus releasing engine overhead; a faded prop is not rendered anymore and engine resources will be freed and allocated elsewhere.
    Your map geometry will dictate the proper fade distances, but as a rough guideline, small props could have a fade distance anywhere from 800 to 1200 units (flower pot on a window sill, small bucket at the back door, a bottle on the sidewalk…), while medium props could do with 1400-1800 range (a shrub, a power box on the wall, an antenna on the roof, wood plank, gutter pipe, fire hydrant…).
    Be very careful though not to prematurely fade critical props used for cover or game tactics (car in the middle of the street, sandbags, stack of crates, dumpster on the sidewalk…).
    Cheap assets
    Many people forget about this technique which is more than needed when it comes to open maps that tend to have larger average PVS than traditional maps.
    I showcased in a previous article of mine the fps cost of cheap and expensive assets (Source FPS Cost of Cheap and Expensive Assets).
    Get in the habit of using the low-poly model version as well as the cheap texture version in the distant non-playable areas and the high unreachable areas where players won’t have much of close contact with the environment. Potential candidates could include a distant field, the unreachable opposite bank of a river, a garden behind hedges/walls, high rooftops, the 3D sky…).
    Fog/Far-z clip plane
    This technique, when correctly used, can provide a big boost to your frame rate as parts of the world beyond the opaque fog won’t be rendered at all.
    For this technique to work properly, your map should have a foggy/rainy/stormy/dusty/hazy/night setting (use as applicable) where a fully opaque fog won’t appear out of place. Obviously, if your map takes place in a sunny and clear day, this technique won’t work much and it will look inappropriate.
    Using this is simple: For example, if your map is set in a rainy and foggy day, you just need to set the fog end distance while having its density set to 1. You will then set the far-z clip plane to something slightly higher than the maximum fog distance (if the fog end distance is 8000 units for example, the far-z could be set to 8200).
    3D skybox
    This is another good technique to reduce engine overhead and the cost of rendering.  
    It is true that the 3D sky is used to expand the limits of your level and decorate its surrounding, however, since it is built at 1/16 scale (and expanded in-game), it is also a nice way to decrease rendering costs. Use this to your own advantage and relocate assets in the non-playable areas with limited player interaction to the 3D sky.
    One thing to keep in mind though, the 3D sky’s visleaf is rendered at all times on top of the PVS in the playable area. Do not go overboard and make an extra complex, highly expensive 3D sky or you would be defeating the purpose of this optimization technique.
    Occluders
    You thought I forgot about occluders? Not a chance as these are the big guns when it comes to large open maps with little world brushes to use for other optimization techniques.
    Let’s clear one thing first; if your map is made mostly of brushwork and displacements with little to no props, then there is absolutely no need to resort to occluders as they’d be totally useless in this case. Only when the map is loaded with models and props in an open setup with little regular world brushes that occluders come to play in force.
    To place occluders, you would search for areas where these occluders could make the most impact (low fps, high traffic, props abundance) since they run in real time and are expensive, otherwise their cost would outweigh their benefit in terms of frame rate variation.
    Remember that occluders rely on the player’s position and field of view relative to the occluder to calculate what gets culled. You need to place them in a way to maximize the number of props to be culled behind them when the player stands in front of these occluders.
    Let’s see some examples.

    We go back to our famous top down diagram; the occluder is dark blue placed on the left wall of the large house while the little black stars represent various props and models. The 2 diagonal black lines denote the player’s FOV relative to the occluder. Anything behind the occluder and within the view frustum will be culled.
    That’s nice; we are able to cull 4 props but is it enough? It is not optimal as we can still do better. What if we move the occluder to the right wall of the house?

    Much better if you ask me. 5 additional props were added to the culling process meaning less overhead and fewer resources to render for the engine. That is why I said earlier it is all about maximizing the impact of the occluder by placing it in a way relative to the player’s position that maximizes the number of culled models.
    Here’s another example (still top down view).

    The player has moved to the middle of the central street, and beyond that L-shaped house is an open field with a lot of props scattered around. One way to implement occluders is as showcased in the above diagram. Notice how I arranged 2 perpendicular occluders along the walls for the maximum occlusion effect as all of these props in the field are not rendered from that player location.
    Another way to arrange occluders in this case would be diagonally across the L-shaped house (split into 2 or 3 occluders if needed to accommodate the nearby geometry; they can be floating without the need to seal an area).
    If you’re feeling brave enough (you should be after reaching this far in this article), you could also add an extra occluder along the wall of the house to the left of the L-shaped house to further enhance the view frustum occlusion effect and cover more props in the field.
    The most common places to add occluders in open maps include a displacement hill that separates parts of the map, a hedge that stands between a street and a field full of props, a floating wall between a house garden and the street, the walls of a large house, the walls of a tall building, a ceiling when it separates multiple levels…
    To read more about occluders placement and cost, please consult my article Practical guide on occluders placement
    In conclusion
    The foundation of optimization in Source engine will be the same whether it is a traditional map or an open one. You will heavily rely on func_detail, nodraw, displacement, props… to achieve your goals but it is the way you use these tools in an open map that makes all the difference.
    One might get away with being a bit sloppy with optimization in a traditional map, however, make no mistake that an open map won’t be any forgiving if you decide to skip a beat in your optimization system.
    Talking about different open maps and formulating varying optimization systems for them could fill articles; I hope this article has shed enough light on the open maps optimization approach to let you easily design a system for your own map.
  4. Like
    Squeebo reacted to will2k for an article, Viability of Hostage Rescue Scenario in CS:GO   
    This level design article is about the past and the present of the hostage rescue mode in Counter-Strike. Showcasing the inherent issues that accompanied the scenario allowing the bomb/defuse mode to gain traction and popularity. This article will also present what can be done, level design wise, to remedy some of the shortfalls and allow the scenario to be viable.
    A historical background
    Counter-Strike officially started life in June 1999 with the release of beta 1, and it shipped with four maps, that’s right, four whole maps. They were all hostage rescue maps and the prefix used for these maps was cs_ as opposed to the standard deathmatch maps starting with dm_. This prefix was an abbreviation of the game’s name (Counter-Strike) which hints to this hostage-rescue scenario being the only one in the minds of Gooseman and Cliffe, the creators of CS, at the time of launch.
    Fast forward a couple of months, beta 4 rolled out in November 1999 bringing to the table a new scenario, bomb defuse. The new maps carried the prefix de_ and while one would think that the hostage rescue maps would be switched to hr_ prefix, they kept the same prefix which started to be referred to as the “Classic Scenario”. Counter-Strike was built on hostage rescue scenario.
    I started playing CS in beta 2 in August 1999 (I totally missed beta 1, screw me) and maps like Assault and Siege were all the rage at LAN parties. The nearest LAN/internet café was a 5-minute drive from my place, and LAN parties with friends used to be a blast full of shouting, cursing, bluffing, noob-trashing; the standard menu for a CS session. Good times.
    Siege, the oldest CS map (beta 1), and Assault (beta 1.1) were the epitome of the game. You had to dive in as a CT deep into the T stronghold to rescue the hostages and bring them back to safety. These maps were the most played on LANs and embodied the style of early CS gameplay. At the LAN place where I used to wage my virtual battles, Assault equaled CS, literally. A fun fact is that when Dust came out, I started a LAN session with this map and everyone in the room shouted at me: "What the hell is this? We wanna play CS!" For my friends, Assault was CS.
    However, those rosy days for hostage rescue began to turn into grim grey when folks started playing bomb defuse scenario and realized how…fun it was. A map like Dust almost single-handedly pushed the scenario into higher ground with its bright environment/textures, clear/wide paths and its ease of use and noob-friendliness. A year later, around Summer 2000, Counter-Strike was now equivalent to Dust for my friends.
    How did this happen? What went wrong?
    Inherent flaws of hostage rescue
    Hostage rescue is a very delicate and tough scenario for law enforcement operators in the real world. It puts the assailing team at a great disadvantage against heavily-armed barricaded hostage-takers who are probably using civilian hostages as human shields and as a bargaining chip for a later escape.
    As you can deduce, transferring this scenario as realistically as possible into the game will not fare well, and this disadvantage will carry on for the CT team. The problem is only exacerbated when you add the more or less “flawed” game mechanics to the scenario. This is exactly what went wrong with hostage rescue scenario in case you are still wondering about the rhetoric questions at the end of the historical background introduction. The popularity of cs_ scenario started dwindling and the rise of the bomb/defuse scenario only made things worse.
    Almost all the early cs_ maps featured a relatively tiny hostage zone/room having one entryway usually sealed with closed doors that the CT must open to get access inside. This room was typically located behind T spawn which made the area a camping ground and made camping that zone an obvious and rewarding tactic for Ts. The doors having to be manually opened with a loudening sound made things worse and negated any surprise or sneaky rush towards the hostages. A classic example is the hostage area and T spawn in cs_assault.

    I dare not think of how many Ts are camping behind those doors
    Another equally important camp fest occurred in the hostage rescue zone. Early designs made the rescue zone relatively small with one or two access paths that can be defended from one location. If the CT team manages to reach the hostages and rescue them, the Ts could easily fall back to the rescue zone to camp and patiently wait for the CTs to show up. The hostage rescue zone in cs_italy is a nice example to showcase how one T could camp in the southernmost spot in the zone allowing him to monitor both entryways, from market and from wine cellar, within the same field of view. CT slaughter was almost a guaranteed thing to happen.

    A CT will show up any second now; imminent slaughter commencing in ...3, 2, 1
    A third flaw was the hostages themselves. They were difficult to escort and protect and were easily stuck or left behind in various parts of the maps between their initial hostage zone and the final rescue zone. I lost count of how many times I rescued the hostages and ran as fast as I could to the rescue zone, reaching it with a big grin on my face only to turn around and find out that only one or two of the four hostages actually followed me; the others were randomly stuck on a ladder, door frame, window ledge, vent, chair, table…I could go on but my blood is starting to boil just thinking of this.
    To add insult to injury, hostages could also be killed or “stolen” for ultimate trolling. When Ts were stacked on money, they could easily kill all the hostages, basically turning the round to a frustrating terrorist hunt for CTs. In early CS versions, a CT teammate could press the “use” key on a hostage that you were already escorting to steal it. This would leave you helplessly wondering where the hell did the 4th hostage go in case you did not catch the teammate performing the action.
    Lastly, maps themselves contributed to the issues that were piling up against hostage rescue scenario. If you are a CS veteran and you were around the early betas in 1999, you would most certainly remember how quickly hostage rescue maps were pruned from one beta to another; some maps even had a life span of 1 week before being discarded out of the official roster. Most of these early cs maps featured dark, nightly environments that were unfriendly to both newcomers and established players. Other maps had a confusing-as-hell labyrinthine layout that confused even the most great-sense-of-direction players, and made remembering paths nigh impossible. Some of these maps had narrow twisted paths and choke points, vents, and ladders that not only frustrated players (especially CTs) but also made rescuing and escorting the hostages more of wishful thinking. The icing on the cake was the different gimmicks introduced in some maps that made a frustrating gameplay/layout even more annoying: some maps had a machine gun nest in T spawn allowing Ts to master and perfect the art of CT slaughtering while other maps had flammable drums that could be shot and blasted for the ultimate carnage right next to the hostage zone. Good example maps include cs_prison, cs_bunker, cs_iraq, cs_hideout, cs_facility, cs_desert, among many others.
    Meanwhile, bomb/defuse scenario was gaining grounds at an increased rate and before too long, hostage rescue was relegated to a distant second place in terms of popularity among players and level designers alike.
    As a small experiment, I tallied the number of custom hostage and defuse maps submitted on Gamebanana for Counter-Strike Source and Global Offensive. For CS:GO, there are 761 de_ maps against 157 hostage maps while for CS:S, the figures are 4060 de_ for 1244 cs_ maps. The disparity is rather meaningful as the ratio in CS:GO is 4.85:1 while for CS:S the number is 3.26:1. This means that for each hostage map in CS:GO there are almost five maps of bomb/defuse whereas this number drops slightly to almost three maps for CS:S. With CS:GO putting extra focus on competitive gameplay, this ratio is bound to further grow widening the rift between bomb/defuse and hostage rescue maps.
    That’s it? Is it done for cs_ maps? Shall we prepare the obituary or is there a magical solution to breathe some fire and life in them?
    Solutions for viability
    There is a magical solution that involves you transferring a large sum of cash to my bank account, then my “guys” will contact your “guys” to deliver the “solution”. The drop point will be at the…apparently, there has been a mix-up, this is for another “deal” …nervous chuckle.
    Seriously though, while there is no magical solution that will lift hostage rescue onto the rainbow, there are a couple of things that level designers can do to start injecting some momentum to the scenario. Luckily for us, Valve has already paved the way (so these “Volvo pls fix pls” do work after all?). In March 2013, Valve introduced a major CS:GO update that completely overhauled the hostage rescue scenario mechanics and introduced cs_militia as well. The update was a game changer and a much needed tweak towards a better hostage rescue gamemode.
    We now have two hostages instead of four, and the CTs only need to rescue one of them to win the round. Moreover, the hostage does not stupidly follow the CT but instead is carried on the CT’s shoulders. Obviously the movement speed of the CT carrying the hostage is decreased but this “inconvenience” is countered with added bonus round time and the fact that the CT doesn’t have to glance over his shoulders every five seconds to make sure the hostages are still following him (this kind of distraction can prove fatal to the CT escorting the hostages). The hostages’ spawn location is randomized and can be controlled by the level designer. A nice change is that hostages don’t die anymore thus cutting any chance of Ts trolling (you still lose money when you shoot a hostage – shooting a hostage is pretty pointless now akin to shooting yourself in the foot).
    This is all good news if you ask me; hostage rescue is on the right path to become popular and viable again. With Valve doing the first half of the change, level designers have the duty to continue with the second half.
    Hostage defuse?
    As a first suggested solution, let us start treating hostage rescue as bomb defuse. Let’s be honest, bomb defuse works really well, so why not transfer this “experience” into hostage rescue. What we can do is to have a hostage rescue map’s layout mimic one of bomb defuse – that is have two hostage zones that are similarly placed as two bomb sites. We need to start treating a hostage zone like a bomb site with all accompanying techniques of rushing, pushing, faking, peeking, holding, smoking, flashing, etc. The good thing about this is that whatever knowledge, skill, and layout awareness that players have acquired from defuse scenarios will transfer effortlessly to the hostage rescue scenario; you do not need to learn new tactics and strategies. The roles will be inversed: instead of Ts rushing bomb sites and CTs defending, CTs will push hostage zones and Ts will defend and rotate.  
    Sounds logical, right? Some people might argue that having 2 separate hostage zones is not “realistic” and my answer is Counter-Strike was never about realism (carrying and running around with a 7 kg (15.5 lb), 1.2 m (47.2 inch) AWP sniper rifle with 25x telescopic sight, quickscoping and headshotting opponents is the epitome of “realism”). If you want a realistic hostage rescue scenario, then you are better off playing the original Rainbow Six Rogue Spear and SWAT 3 from 1999, or the more recent ARMA and Insurgency for a realistic military setting. I practice what I preach and I already implemented this technique in my last map “cs_calm”. The map was a remake of my CS 1.5 map from 2003 and obviously I made the “mistake” at that time to follow the trend set by official maps of having one hostage zone right behind T spawn. A playtest on Reddit CS:GO servers back in March 2015 confirmed that this setup won’t work well as Ts will inevitably abuse the hostage zone.
    I made some radical layout changes towards T spawn and hostage zone and created two new hostage zones on the upper and lower levels of the map that are connected by a back hallway to allow quick rotations (in addition to the one through T spawn). Obviously, there is no direct line of sight between hostage zones to prevent 1-zone camping. Ts have absolutely no incentive to camp one zone as CTs can reach the other one, rescue the hostage and head back to the rescue zone without being spotted from the other zone. CTs actually have a chance of winning the round by rescuing the hostages.
    I like to believe the new layout worked well. Only time and more hostage rescue maps will tell.

    Layout of the map "cs_calm"
    Rescue zone anti-camping
    We have remedied the hostage zone camping but we still need to tend to the rescue zone camping issue. A solution to this is to have two rescue zones in a similar setup to what is nicely done in cs_office. While Ts can still camp one zone, they risk a big chance of having CTs reach the other rescue zone. Again, CTs will have a viable option to save the hostages without being shredded by camping Ts. If the layout does not allow or facilitate having two rescue zones, then one big rescue zone with multiple entrances (three is a good number) should work fine. The trick here is to have the entrances not easily covered within the same field of view to prevent camping.
    Into the zone
    Just as we established that we should treat hostage zones like bomb sites, it goes without saying that each hostage zone should have at least 2 to 3 entry points. It’s pretty pointless to have only one entrance as this totally defeats the purpose of spreading hostages into two zones. The different entryways should also not be covered within the same field of view of one T; if a T decides to camp the zone, then he should be able to cover two entrances from one point leaving the third one more or less at a dead angle and viable for a CT rush or stealth/sneak surprise. 

    Showcase of Hostage Zone A on the map "cs_calm"
    The above screenshot showcases “Hostage Zone A” in cs_calm. A terrorist will typically camp near the hostage covering the two encircled entrances. The third entrance from upper level denoted by the arrow is not in the direct FOV, and is prone to a surprise attack by CTs that could catch the camping T off guard. If possible, try to spread the entrances on different vertical levels to spice things up and keep Ts on their toes.
    Lastly, it is a good idea to have a connector between hostage zones to allow fast rotations but without having a direct line of sight between hostage zones. We want to make the scenario fairer to CTs but not at the expense of Ts, inadvertently making it unfair for them.
    Conclusion
    Hostage rescue is a fun scenario if you ask me. It had many inherited and added flaws that contributed to its waning but it’s nothing that can’t be reversed. We, as level designers, need to push some changes to put the scenario back on track. What I just showcased in this article might not be the only viable solutions but they certainly are a step in the right direction. Level designers are intimidated by players who shun away from cs_ maps, and this turns into a vicious circle where players avoid hostage rescue maps and mappers in return avoid designing them. We need to break this cycle and designers need to bravely embrace the solutions I presented here or come up with their own solutions. The more cs_ maps that come out and get tested, the more we could validate these solutions as viable.
    In either case, we need to get proactive towards hostage rescue scenario; after all, this is the cornerstone that Counter-Strike was built upon.
  5. Like
    Squeebo reacted to will2k for an article, Displacement Vs. Func_detail - A comparative fps study   
    What is the question?
    Ever since the dawn of humanity, this question was the center of a colossal debate. Greek and Roman philosophers tried to solve it to no avail. Alchemists in the Middle Ages gave it a go and failed miserably. Even Industrial Age scientists touched on the subject with no big breakthrough.
    Luckily for everyone, I am here today to answer this question and put an end to a centuries-long argument: What is better in terms of fps, func_detail or displacement, in the context of the Source engine? If you were expecting an existential question, I am deeply sorry to disappoint you but hey, life is full of disappointment.
    The study
    This is going to be a short but sweet article; fewer words, more numbers and screenshots. The study is pretty straightforward and systematic. To make things fair and square, I will create 2 exactly identical test maps: In one, everything will be turned to func_detail while the other will have everything switched to displacements. I will then proceed to record the localized fps in these maps from a preset location and compare. Pretty simple, isn’t it? Well, it should be as the whole purpose of this study is to compare func_detail vs. displacement in absolute terms while keeping all other parameters constant.
    The cases
    The first map to test is the one made of displacements. Here is the screenshot showcasing the fps.

    The map itself is very simple consisting of 7 identical houses placed at predetermined locations and surrounded by 4 walls. The houses are detailed enough to put some slight pressure on the rendering engine. For the skeptics among you, here is a wireframe in-game shot to show that everything is made of displacements.

    To refresh your memories, in Source engine wireframe mode, green is displacements, pink is brushes (world, func_detail, brush entity, etc…), blue is props, and yellow is decals/overlays. The recorded fps in this map is 289. We now move to the second map, the func_detail version to check how the frame rate is faring. Here is the awaited screenshot.

    Surprise, surprise. The fps is 330, much higher than the displacement version. Here’s the wireframe shot to put your mind at ease.

    Honestly, I was thinking the figures would be more on par as the engine handles both details and displacements pretty well, but in the end, Source is about BSP so I guess brushes would get a slightly preferential treatment over polygon meshes (conspiracy theory ensues).
    The question that forces itself now is: Should we rely solely on func_detail in our maps? Of course not. Both func_detail and displacement have their advantages and inconveniences and leaning exclusively on one will inevitably lead you to a dead end. The best thing to do is get the best of both worlds by using them together.
    In our little test map, how about we mix things up in a third version: let us make the house walls out of displacements while having the doors, windows, frames, and roofs made of func_detail. Incoming screenshot, brace yourselves.

    Much better, isn’t it? We have now 311 fps, a very nice middle ground between the 330 fps of func_detail and the not-so-bad 289 fps of displacements. The mandatory wireframe shot follows.

    So, what can we learn from all this? Well, apart from the obvious places where displacements are mandatory for the organic mesh sculpting (rock formations, cliffs, bumpy/twisted roads…), it is a good idea to spread some more displacements around your map to alleviate the total brush-count that you will inevitably hit the maximum in a highly detailed map. Your fps will remain high and you will enjoy the margin to keep adding structures to your map without fear of reaching the maximum allowed total brushes (substituting brushes with models/props is another viable solution that is not in the scope of this article).
    I’m a man of science and I know that one example is not enough to draw conclusions. That’s fine, I have a second test map to investigate what we established before. The concept of having 2 identical maps is still the same, however, this time, we will spice things up by adding some static/physics props and some decals here and there. We will start with the displacement version.

    230 fps, not too shabby. Let’s check another angle.

    220 fps, more or less, on the same level as the previous number. Now for the wireframe shot.

    The tree cards in the background are func_brush in both maps (the detail and displacement versions), so it’s a level playing field in this case.
    Now for the moment of truth you all have been waiting for: will the detail version have better fps to support my earlier findings or will I be publicly embarrassing myself? A screenshot to the rescue.

    I knew I was right, never breaking a sweat (apart from the nervous cold sweat I just wiped off my forehead). 255 fps for the first location A. Let’s check the other angle or location B.

    250 fps. Bam, sweet victory…sorry I got carried away a bit. Ahem…Let’s get back to being scientific, shall we. Here’s the wireframe proof.

    Let’s recap all the action and numbers in a nicely formatted table.

    You can notice the fps gap between the func_detail and displacement versions in both test maps whereas the “mixed” version considerably narrowed this gap. The numbers have spoken.
    The bottom line
    The bottom line is, if you rely only on func_detail, you will hit the maximum brush-count allowed in Source and severely limit your map and creativity. You might also run into T-junction issues as well as parts of your geometry flickering and disappearing from certain angles in densely func_detail’ed areas.
    On the other side, if you stick to displacements alone, then you will have lower fps than a func_detail map version. You might also run into visible seams and un-sewn displacement issues.
    Having a clever distribution of both func_detail and displacement in your map is the way to go. You will have high fps, better lighting around the edges, and organic sculpting while not getting anywhere near the total brush limit; the best of both worlds.
     
  6. Like
    Squeebo reacted to FMPONE for an article, Making a Map: CS_Museum   
    The creation of a map begins with an idea.
    In the case of my most recent project, CS_MUSEUM, I needed a basic look which would resonate with players immediately. The thought of making a Museum worked… it was a simple one, it had been done before (although this wouldn't be a re-make of the classic DE_MUSEUM by Theropod-X). Players would understand a Museum environment, and it fit in the Counter-Strike world.
    Forming a map’s final look is complicated, though, and requires thought about what kind of architecture, colors, and lighting you – an artist or level designer – will pursue.
    I’d been playing a lot of the classic map CS_OFFICE, which requires players to storm into close quarters for indoor combat. That kind of game-play is fast and unforgiving, I dig the kind of matches it creates. CS_ASSAULT, I shouldn't forget to mention, is another great map that defines the "siege a building and rescue the hostages" genre. Actually, most of my favorite CS_ maps including Militia also foster similarly dynamic games that challenge you to be sneaky but also use brute force to accomplish your objectives.
    So, I set out to make a hostage rescue map like Office and its kin. Studying prior maps is a good way to establish what works well, and avoid what doesn't.
    One other map that influenced my thinking: CS_CABARET by Alex Roycewicz.
    Cabaret is a great map — it got Alex a job at Infinity Ward long prior to that illustrious studio being kicked in the nuts super hard by mega-publisher-that-will-remain-unnamed.
    It was from Cabaret that I basically ripped off the front of Museum... with a few changes.
    In truth, though, I had some bones to pick with Cabaret.
    Unforgivably, there was no sense of vertical space on the outside of the strip club. Also, while the building exterior is convincingly rendered, the overall space is too geometric: everything seems to face the viewer on an imaginary grid, which is no coincidence, that’s how the Hammer editor encourages people to make maps.
    Cabaret on the grid:
    Museum screws the grid:
    If this analysis is starting to sound harsh, it’s worth noting that Cabaret was one of the best custom maps of its time, so this is more of a modern critique of older game art.
    As is often the case with older game art, most of the limitations or flaws obvious to modern eyes were not the creator’s fault: Hammer around the era of Counter-Strike: Source (for which Cabaret was made) did not have all the technology I made use of for Museum. One example is “instances” (the pale green elements in the overview above) which are brushwork more akin to models than typical brushwork, because they can be rotated “off the grid” and not cause compilation problems normally associated with brushwork which is off the grid. Thanks to instances, I was able to rotate buildings to achieve a more natural, organic look — such as this bridge:
    In order to actually create the specific buildings in the map, concept art and photographic references were key.
    Here's an explanation of the Museum front.
    End product:
    First iteration:
    Reference photograph:
    The most pertinent point to make here is the difficulty of knowing when a photographic reference is valuable, and what makes it valuable. To explain this in extreme detail might be delving into an area of “talent”... or it might be worth the subsequent explanation I’ll now provide. In any case, this should explain my process.
    The best photographic references share one crucial element: readability. Complex buildings such as the one above, if they are to be useful for our purposes, must be able to be broken down into clean, clear shapes. I was confident using the logic explored in the line-work above (I did this part in my head), that the building could be broken down and translated successfully.
    The building begins to take shape, with the red lines becoming props. When using Hammer, what becomes a prop and what remains brushwork largely comes down to the default assets you have to work with.
    Talented 3D modelers have their choice of creating new content, but their time is precious and each art asset is an investment, so even then it’s best to think about default materials and their role in your work.
    This lovely picture inspired the placement of the obelisks, and secondarily the pond on the right of the Museum.
    Using concept art and photos in conjunction with my imagination, I had derived a basic visual identity for the map:
    Obvious reference: the Brooklyn bridge; non-obvious reference, this lovely piece from Deviant Art:
    Making a map is about looking at the world around you and seeing something inspiring enough to create a desire within you to render it and mold it for your own purposes.
    By this point in time you may be shouting IT’S A MAP – TALK ABOUT THE GAME-PLAY, TALK ABOUT THE GREY-BOXING YOU FOOL! …and, while the playability of Museum ended up better than I could have imagined, there is no glory in my process for that particular aspect of the map. Uh oh, he’s gonna say he didn’t grey-box it, isn’t he…
    First, the excuses: previously, I'd recreated the Natural Selection 1 map NS_VEIL for NS2, based solely upon my own literal eyeballing of the geometry, without any scale-guide, in a different editor and a different unit system. To put all that gibberish into other words, I’d done nothing for two months other than study the rigid grey-boxery of another mapper, then spent another 10 months making that geometry fit into the context of a new game and engine. I’d worked with fastidiously organized layers, done everything by the book, guv, I swear.
    While important for a commercial product, that experience had temporarily tired me somewhat of the (smarter) formalistic approach. As a result, no substantial grey-boxing would take place for Museum. Manic energy took the place of “rules” and “common sense”:
      Basically, I was creating stuff I thought looked cool, not getting terribly fussed about what direction it would all head. This is the way newbie mappers work, or idiots, or both… but it can be done if you’re smart about it.
    Certain things can’t be bullshitted around, though: your map must be in proper proportion to the players, and it must maintain sensible sight-lines considering the game type. You need to know the game you’re making the map for, and know it well.
    So working free-form has its advantages, creating a whimsical sense of liberation in the budding mapper. It comes at big costs to him, though, in other aspects. This open doorway, and the entire route it signified, never made it into the final product. People have noticed its conspicuous absence, however, to the point that it may make it's return soon enough.
    Working toward a result, with certain restraints in mind, but willing to cut: my method for Museum.
    Mistakes were made. Certain areas violated basic good-practice principles, such as this one:
    I call this piece of modern art “Abstract Red Light Number 48.” So… this elevator shaft was painful for a few reasons: too noisy inside, not clear enough about what it was meant to be, and the idea of it having a purpose seemed impossible given the amount of crap stuffed into the scene.
    I believe I settled on a better, cleaner result:
    Which was based off of this reference:
    This shipping area was another idea that got cut (considering that it was over-dark, this was not too sad):
    Based on:
    Everything else seemed to go swimmingly, however:
          My biggest advantage when working with these references is my ability — and perhaps your ability as well — to discern from them what elements are most relevant and work best geometrically. These judgements influence what makes it into the map. While you may be able to follow a similar protocol by examining the pictures, you would be doing so in hindsight; it was quite necessary during this project for me to be able to sift through literally thousands of images in order to find those which, at first glance, provided the requisite inspiration.
    References must be clean, they must convey a certain tone, and the architecture they illustrate must be plausible among the rest of the map geometry. This process of looking through seemingly endless references is a task which must be begun anew with every new map.
    Back on topic: a month or two after starting out on the map, I recruited a talented 2D artist named penE who had a style congruent with mine. With his help, rooms like this began to form their own identity:
    The map began to develop a sense of humor. We based the name of the museum on HURG — Hero of MapCore! (Don't ask.)
    PenE brought his full enthusiasm to the project, getting almost all of his work done in a month or so, a rapid pace which would be a major motivator for me while I was working with (read: waging war against) the Hammer editor.
    Here is a sample of penE's work for the map:
      Nevertheless, the map did seem to require more art…
    I had envisioned a T-Rex in the above room, and had designed the room around that eventuality. I was concerned that such a 3D model might not fit well (it’s a relatively cramped room), or might not be appropriate looking, but I put out a call for a talented 3D artist.
    3Dnj answered that call with a stunning T-Rex model based on square-shaped geometric restraints. I basically stacked a bunch of cubes on top of one another and said, “OK now make me a T-Rex that fits inside the squares.” Seems hopeless, right? Thankfully, Valentin, as 3Dnj is known, e-mailed me this bad boy:
        Owns right? Imagine waking up and seeing that first image of the T-Rex with that brilliant sheen, I was ecstatic.
    At that point I realized I’d found a true collaborator and not just a “prop guy”. Valentin would go on to help me optimize the map, and reform a lot of my map geometry into more sensible models. Here’s how crazy things had gotten:
    Hammer is unlike a modeling program in that it is “brush-based”, and things that are not literally six-sided cubes give the editor trouble. Trying to create an interesting shape out of a single brush? Take a hike.
    So it’s obvious why a more extensive collaboration was needed: it was never going to be realistic to proceed in such a manner and expect an optimized result which would (ugh) compile. Hence, the logic of making a map which looks the way Cabaret does, unfortunately all the same limitations applied more or less in 2012, with just a few exceptions like instances.
    So there were technical challenges, but four months on, most of the major lessons of the map were learned and my vision for the map was realized almost exactly as it existed in my brain.
    My workflow can be best summarized as: find a fitting photographic reference, get a basic interpretation of the geometry into the game, and then polish with aesthetics and navigation in mind (lead players with lights and colors).
    Phase 1:
    Phase 2:
    Phase 3:
    Rather than attempt to convince you I pursued the traditional level-design approach of iterating a grey-box, I hope this document serves to explain the approach I actually took: a risky and improvisational one that I know I’m lucky was successful. It’s good to state how lucky: a layout that emerged without argument, finding two brilliant collaborators with a lot of faith in the project, etc. Hopefully anyone looking to duplicate my exact method will be given pause, but at the end of the day there will always be logic in working hard and having a well-formed mental image of your goal.
    As for Museum, I can promise you one thing: if you load up the map, and I hope you will, I think you will enjoy it. (If only for the giant, motherfucking Tyrannosaurus Rex.)
    Thanks for reading.
×
×
  • Create New...