Jump to content

Evert

Members
  • Posts

    2,459
  • Joined

  • Last visited

  • Days Won

    2

Reputation Activity

  1. Awesome
    Evert reacted to General Vivi for an article, Designing Highly Replayable Stealth Levels for Payday 2   
    The Making of Murky Station: Payday 2
    Payday 2 is a four player cooperative first-person shooter with RPG elements that centers around robbing banks and stealing rare loot. It was released on August 13, 2013 and has since shipped over 50 DLC packs and counting. With a thriving subreddit, it has consistently been in the top ten games played on steam. Today, I wanted to talk about my adventures designing stealth levels for Payday 2 before leaving Starbreeze in January 2018. While parts of this article are specific problems and solutions for Payday level design, I made sure to discuss them in a broader sense. The skill level of this article is for junior to mid-tier level designers, if you are a senior designer some of this article may sound familiar to you.
    I'll start off by saying that Payday's stealth mechanics are not perfect and can be flawed in some areas, but I wanted to focus on the decisions behind the map design, specifically for the heist Murky Station. I'll also break down how we consider using RNG (randomization), and the ways we apply it to objectives and mechanics to keep the level fresh and replayable. This map took 6 weeks to make between 2 people. My partner took the role of Level Builder / Environment Artist and I took the role of Designer / Scripter. Between the two of us, we figured out the scale of the project based on the needs of our studio. The idea was to create a small heist that took around 10-15 minutes to finish with high replayability. There's a lot to go over, so let’s get started!
     

     
    Let's start from the beginning
    Before we start drawing or building layouts, we make the call if we are going to create a Loud level (combat only), Stealth level (avoid combat), or Mixed style map. For the short period of time given to us, we decided to stick to stealth only. Making this decision early on helped us create better movement options for the player and focus our efforts towards balancing patrols and objective placement. We decided that the theme of the level was a small train depot run by a group of mercenaries shipping large weapons. The main objective was to infiltrate the depot and steal an EMP bomb. Keeping the objective simple and intuitive is important in multiplayer games where players can drop in and out of the experience at any point in time.
    We decided to shoot for 10 - 15 minutes of gameplay. Breaking down our main objective into smaller sub-goals that could take about 2 minutes each (this is based on our extensive knowledge of payday 2). It should be noted that this time assessment will change once the player has completed the level a few times. These numbers tend to get cut by a third, or in some cases, by half. With our main objective in mind, we can construct a simple flow diagram for the heist and start to think about possible dynamic and RNG elements that can be used to create a re-playable experience.

    (This is a scripting example from our editor, each entity has it's own function)
    Testing your ideas before scripting them? Wait... What?
    Since 90% of Payday levels are hand scripted, it's important we don't waste time building the wrong things. Testing your objectives and complicated RNG elements has to be fast and efficient. The last thing you want to do is build an entire system and find out it sucks. Most of the time you don't even need animations or even a model to properly test your ideas. At such an early stage some floating debug text will do just fine. You might be asking, what if I don't have debug text or the ability to script? When playtesting levels for Payday 2, a lot of the time we'll get a simple block-out done and then ... here it comes ... pretend we're doing the objectives.
    It might sound crazy (and not everyone can get through it without laughing) but we'll have one of the designers act out the role of Bain, our mission giver, and just spout objectives at us. We'll move through the space and pretend to see guards or hack laptops and delay time based on things we expect to happen. You can basically break down how your systems might work and try out a few possibilities. For example, knowing that you might have two escapes at either side of the map gives you enough knowledge to make pretend decisions. Telling your fellow devs the van is arriving up top and pointing out where to secure loot can help you find out if a location is interesting for the escape or not.
    Even though the artists might giggle, or people from the other teams walking by stop and wonder why they can't see that hoard of enemies. It really works, and can often steer the level in the right direction and prevent us from investing too much time on the wrong objectives. Now, I know this approach won't work for all studios or situations, but all I gotta say is... don't knock it till you try it...  
       
     
    Constructing our Sandbox Layout
    Now that we've pretended to run through our objectives and have gotten used to our basic block-out, let's talk about the layout we built for Murky Station. We went for what i'd like to call "the onion approach", which is pretty much what it sounds like. You'll have multi-layered rings that give you the sense of progression towards the center (or a goal). Essentially, we use the outer layer as the player start and each sub-objective is based inside a different layer until the player reaches the main objective (at the figurative center). This approach is very useful when working with sandbox type levels, especially when the player can virtually go anywhere they want.

    Side Note: We also layer our music track each time a sub objective is finished, creating more suspense and a sense of agency.

    You can see that the outer onion layer is the player spawn (colored green) on the overpass which gives them a full view of the trainyard. From here they can study patrol routes, train-car positions, and possibly objective locations. The overpass can also be used by a player with a sniper rifle to mark guards in the different lanes, helping provide accurate information on guard positions for the players on the ground floor.

    The next layer is breaking into the train yard through a fence around the perimeter. The fence is here to guide the player and give them a visual boundary for the "safe zone" (where no guards patrol). The next layer is searching the train cars to discover where the main goal is hiding, followed by breaking through the vault doors inside of the trains themselves. These onion layers have to be carefully managed to give the proper impression to the player. Too many layers and you might confuse the player or make them forget what they're doing, too few and you might leave them feeling unchallenged or unaccomplished.
     
    Player Mobility is key!
    Mobility is key to providing players opportunities to express themselves and make better decisions while traversing a level. I felt that it was pretty important for Murky Station to allow for different play styles ranging from slow and methodical to fast and dirty. The last thing I wanted was to force players to play a certain way or for the routes to become predictable and linear. In order to do this, I spent the first week of development prototyping and testing out different layout ideas that would maximize paths and choices for the player.
    (Here is a simplified top-down of the routes in the train yard area)


    It became obvious that we would need to allow players to traverse through and under the trains as they cover most of the real estate in the train-yard. Unfortunately the older train assets were not built to go underneath, but lucky for us, the nighttime setting of the level would cover up this fact. There being only 2 of us on this project, I took a crash course in Maya and cleaned up the bottom half of the trains by removing collisions and remodeling them for readability purposes.


     
    The next challenge was to teach the player they could hide under trains and be safe. Payday players haven't been under the trains in any other heist up until this point, so we needed to call attention to that but also show them it was a safe place. Making these spaces dark and in the shadows helped create an illusion of safety but also made it harder for players to find them.
    To help solve this issue we added yellow caution tape as a trim and a dim red light under the wheels to catch the players eye. These combined elements would then be used as visual vocabulary in other parts of the level to teach players something should be explored.


    One of the other ways we added more routes to the level was to build a ventilation system in the lower tunnels. Leveraging the fact that this was a stealth level to create these smaller spaces, especially since they didn't have to accommodate 40+ police officers. The vents allowed players to safely view guard patrols, search for objectives, and move loot. To prototype this, I built a modular vent system using basic mock-up units that allowed for rapid construction and testing. Funnily enough, the first iteration of the vents was too small and caused players’ bodies to clip through the floor. I was able to rework my mock-up units and we settled on standing height instead of a crouching one. Once again we used yellow caution tape as our visual vocabulary to highlight the vent entrance on the wall.
    Modifying the trains and vents is one of the factors that contributed to the map’s success and gave new players more confidence to explore the trainyard and lower claustrophobic tunnels. So now that we've explored the different possibilities for movement and giving the player more choices, it's time to buckle down and get our randomization system built.
     


    Randomizing Objectives to Maximize Replayability
    RNG is one of the core pillars of Payday, so every decision we make is looked at through a lense of RNG. We strongly believe randomization should be meaningful to gameplay and not just added for the sake of it. It’s important to ask questions like: was it worth changing all the cups in your level? Did you gain anything from swapping out all of your cars and buildings? Was creating a third entrance valuable to the level? Maybe one day we'll completely randomize every object in a building down to the smallest cups, but in a game like Payday I personally feel these types of things have diminishing returns and can often ruin a planned design.
    When working with RNG it's important that you ask yourself as many questions as possible to start with a strong foundation, especially if you plan on finishing on time. Something I often see junior to mid-tier level designers forget is to build for scope and set priorities on their objectives. It might sound trivial, but forgetting your priorities can send you down a black-hole that eats away all of your time.
    So how did we go about adding RNG into Murky Station? Breaking down our objectives, we can start to consider what RNG options are available and doable within our one month time frame. I've also labeled them with my personal priorities (low - high).
    Break into the train yard randomize breach locations (low) Locate the Bomb Train randomize train configurations (high) Hack into the train randomize panel to flip sides (low - medium) Open the Vault 4 different vault door / key types (high) Find the Vault keys The map supported up to 40 hiding locations (med - high) Secure the EMP bomb parts 2 escape locations, 1 chosen per playthrough (medium) I focused most of my efforts on randomizing the train configurations, vault doors and key placement. These objectives were critical in influencing how the player would move through the main space and how they could tackle the same area in different ways through multiple playthroughs. In order to accomplish this, I broke down my sub-goals into digestible points of interest and isolated them into their own prefabs (shown below). Doing so allowed me to script one prefab and teleport it to as many locations as I wanted. This approach made the randomization more manageable to script and cut down the amount of bugs that might have formed if I built everything by hand each time.

    Side note: We gave each one of our key / vault prefabs its own unique visual and audio so that players could identify them from a distance or listen if they were close by. Providing them with this level of feedback is critical in helping them make proper decisions while traversing the level.



     
    Now that we have our vault doors and keys figured out, I can begin the planning process of placing them throughout the level. When placing them, each location must meet certain conditions before being finalized. The main goal is to provide the player with a challenge and also encourage them to be creative in tackling the surrounding area. Having designed the layout to have many interesting choke points and traversals, it was fairly straightforward where I could place them. Collecting the keys is one of the more RNG based objectives in Murky Station, sometimes all of the keys are in different corners of the map and other times they are all next to each other. Eventually there was a script clean up to prevent overpowered locations or terrible RNG possibilities, but overall it was a huge success for the level.
    We generally kept the key locations central to the layout and tried not to place them too close to the player’s safe zones. Placing several keys along the outskirts was a nice change of pace from the main lanes, providing a different type of challenge due to the openness of the layout.
    This is what the upper train yard looks like and how the keys are distributed. The lower tunnels have the same amount of keys placed.


     
    We also used the same method for spawning the train interiors and vault doors. By creating one prefab and scripting it four times inside the level (one per vault door type) we were able to randomize the location of the players’ main goal with little effort. The engine also allows us to rotate our prefabs, giving us the option to flip the train interiors.  This added a whole new layer to their configurations, since some of the interior layouts were asymmetrical.
    We ended up with roughly 600 train configurations, 2000 vault door combinations, and 256 sub objective configurations. With 1 of 2 exits being chosen randomly each playthrough, this really changed what types of decisions got made by the players. It also influenced how they would flow through the level and took advantage of their diverse set of movement options.
    On top of that we use non-linear objectives, which basically means you can do multiple objectives at the same time or in some cases, different orders. In Murky Station, players can simultaneously be looking for keys, searching through trains, marking guards from the overpass, and securing extra loot they find. This allows 4 players to comfortably split up to cover more ground and work off each other. A well coordinated team might have two players hacking into the trains to find the EMP bomb, while the others are looking for the vault keys. I find it very important to provide all players an opportunity to contribute towards the main goal.
    Side note: With all of this randomization, you might be wondering how QA can test it all. The short answer: they don’t. We need to build efficiently to insure 90% of the level is solid, and then catch as many edge cases as possible. On the Payday team, the frontline of defense for QA is the designer making the level, It’s our job to test our own work thoroughly! The way the systems above were built would only required 1 prefab to be maintained for each example. This provides us the freedom to go nutty with the customization in the level, knowing it has a low chance at affecting our prefabs. So, as long as we build smart we can cut down the amount things QA needs to test and help speed up production.

    With the objectives off to a good start, let's take a look at how RNG might affect our guard patrols and cameras in the level.
     

     
    Guard Patrols and RNG
    Randomization can have a large effect on how smooth or frustrating a level turns out to be. One of the things we have to keep an eye on when designing stealth levels is frustrating the player through poor patrol placement, amount of guards, and how long they pause at each location. The goal is to create a fun puzzle-like challenge, not a terrible waiting game. Bad RNG might have you sitting in a corner for one minute waiting for the guard to leave, only to have another guard take his place when that minute is up. It's our job as the level designer to help prevent such situations from happening by adjusting our timings, reworking the layout, or possibly the level’s mechanics. This is why it's so important to create a solid base for player movement options from the beginning.
    Since we don't want our guard patrol RNG to get out of hand, we need to be careful about how they flow through a space. Doing this requires it's own personal attention and multiple iterations. Tilt too far in one direction and you'll end up with bare areas that have no guards, tilt too far in the other direction and you'll have too many guards stacked on each other with no wiggle room. The last thing you want is the possibility of a death chain reaction. This is caused when you kill 1 guard, only to have another guard 10 meters away spot that body... forcing you to kill that guard, who eventually gets spotted by the next, ect. In Payday 2, players have a limit of 4 guards they can kill before the alarm goes off (on all difficulties). In our levels, we have to actively manage the amount of crossover between paths and how often guards might meet.
    In the first test pass for Murky Station I ended up with a good amount of coverage for my level, but the downside was that some sections could randomly get 8 guards piled up.  After a bit of playtesting and redesign, I decided to break up my patrols into smaller loops and add more points. This increased the amount of coverage and kept the patrols more consistent. It also lowered the maximum guard stacking to around 4 and drastically reduced the amount of death chain reactions that could happen.

    First pass patrol locations

    Second pass patrol locations

    (the new paths provide the same amount of level coverage with a less chance of guard over-stacking) 
    A fresh take on an old mechanic
    In most of our stealth levels we use random static security cameras to challenge the players’ skill at avoidance or sabotage. The players have multiple mechanics in order to deal with them in a variety of ways, but we hit a brick wall when discussing options for Murky Station. Due to the hallway nature of the layout and the surrounding structures, we were left with very few options when it came to camera placement. With so few options, the cameras would be no longer modifying the level in a positive way. We also found them at odds with the design of the level, since you were supposed to be searching for a specific train car. If we had cameras pointing at it, you would be able to identify it too quickly and negate the challenge of finding it.

     
    So how did we fix these issues? Getting rid of the cameras was not really an option, so we began brainstorming and looking for assets that might be of use. It's important the core camera functionality remain intact and also continue to meet our core pillar of randomization. We discovered an old drone asset for one of the previous levels and began prototyping a few ideas. The design we ended up going with provided us the coverage we needed, while also creating a new challenge for the players to overcome.


     
    Each train can spawn up to two drones, which will then fly around the perimeter of the train and scan for players and bodies. Randomly throughout the level, three to four drones will be activated to begin their scan. The loop takes about 30 seconds before they return to their trains and deactivate. The cycle continues like this every few minutes until the level is finished.
    On harder difficulties, more drones will spawn and they will become indestructible.
    What's great about the drones from a design perspective, is that we can dynamically modify how the level gets played and prevent players from getting comfortable in using the same routes each play-through. Some players will avoid lanes with drones, more skilled players will dodge them using their movement options, and some players might even get trapped and need to think of a new routes. Let's take a look at the patrols and drones in action.
    (This clip is sped up about 8x and set to the hardest difficulty to help illustrate pathing and drone movement)
    Closing thoughts
    Murky Station was such an enjoyable experience to work on that I still play it to this day. When you break down the objectives and how they influence one another in a co-op space, you can begin to see the bigger picture and how a well-planned level with controlled RNG elements can stay fresh and replayable. Experimenting with different types of RNG is something I find very interesting, especially when you combine it with level design. I hope my article gave you some more insight into how we build with RNG and why we consider it one of our core design pillars. If you found this article helpful, let us know in the comment section!
    Thanks for reading, here is my Info :
    Twitter: @generalvivi 
    Email: generalvivi [at] gmail . com
    Website: www.generalvivi.com
    Before you go!
    If you enjoyed this article and would like to hear how we used RNG in other ways, check out Patrick Murphy's article on the Payday 2 level "Hoxton Breakout".
    I also have a  speedrun (1min) of the level for you to check out and a playthrough on the hardest difficulty (10 mins) by one of the pros from the community.  
    Fastest time 2018 (warning to lower volume)
     
    10 min gameplay video showing off a lot of variety in the heist. 
     
  2. Like
    Evert reacted to Puddy for an article, Dynamic levels - in Payday 2 and beyond   
    Payday 2 is a cooperative first person shooter where players band together to commit various crimes in the endless pursuit of wealth, infamy and cool masks to cover their criminal faces with. The game recently celebrated it’s third birthday, yet it still retains a steady player base. How then has the game kept players engaged throughout the years? The many and regular content updates are surely a big part of it. Another draw must be the fleshed out progression systems that offer tons of customization. I would argue that the lifeblood of the game is its dynamic level design; it is what keeps the game replayable and fun. In this article I will discuss what dynamic level design is and how it was used to build “Hoxton Breakout”, one of the game’s most popular missions.
     

    Payday 2, Left 4 Dead 2 and even XCOM2 all use some form of dynamic level design.
     
    What is dynamic level design?
    Dynamic level design is all about creating levels that are as replayable as possible; it is about retaining the challenge and keeping players on their toes. This is achieved by introducing elements that change between playthroughs, things that make the level a bit different each time you play. Dynamic levels are still designed and built by hand, so to speak, which makes them different from procedural levels which are created from automated algorithms.
      Dynamic levels are useful in games where the developer wants the levels to provide more gameplay than a single playthrough would. This approach has the added benefit of allowing different players to come together and enjoy the same level, irrespective of whether they have played it many times before or not at all. This can make dynamic level design ideal for co-op games and it can be essential for retaining players over longer periods of time, just like Payday 2 has done.
    Building a dynamic level
    The process of building a dynamic level certainly differs from more traditional single player level design. Instead of crafting a linear experience in meticulous detail, a designer must seek to create a broader structure of what will happen in the level and then design dynamic elements, things that change between playthroughs, within that structure. These dynamic elements need to be designed with care, so that the level actually changes in meaningful ways between playthroughs. The process of making a dynamic level will vary from game to game; it all depends on the game's mechanics, setting and other details. By sharing the design of a Payday 2 level I hope to illustrate what a dynamic level can look like and also showcase the overall possibilities of dynamic level design.
     
     

    Hoxton in all his glory, featured here in this promotional art. Shortly after his breakout, he leads a daring break-in at the FBI to uncover who ratted him out.
    Hoxton Breakout
    In the Payday 2 mission “Hoxton Breakout” players are tasked with breaking their old heisting comrade Hoxton out of custody. During the breakout Hoxton shares his suspicion that his capture was caused by an unknown snitch. To uncover the truth, the PAYDAY gang set their sights on the headquarters of the Federal Bureau of Intervention (not to be confused with any real life organization...). This sets the stage for the mission’s second level and the one I will be discussing here.
     
    Level Structure
    In this level, the players will enter the FBI headquarters together with Hoxton (an NPC). They will fight their way to the “Operations Room”; the place where the FBI servers are kept and where the Payday gang is hoping to find the information which reveals the identity of the snitch. Hoxton will search through the servers and when he has found what they need, the gang will escape. No matter how many times you play the level, the overall structure will stay the same. Instead, it’s the dynamic elements within this structure that change and make it replayable. What are those, you ask? Let’s take a look!
     

    Clockwise from top right: The FBI HQ lobby, a central area in the level. The FBI director hides behind his desk. Hoxton and the Payday gang enter the lobby.
    The Operations Room
    Players will spend a lot of time in the FBI Operations Room. Hoxton will be hard at work searching through the servers, leaving players to defend him from relentless police assaults. The combat space will change in a number of ways between playthroughs.
      Entrances - Most of the entrances to the Operations room are selected dynamically in various combinations, which changes which choke points the player must defend.
    Windows - The ‘Operations’ room is two floors in height and the second-floor windows overlooking the room are placed in different positions. Players must watch them for enemy fire.
    Fuse box - The fuse box, which enemies use to cut the power to the servers and pause your progress, can be placed in a few different positions. Players must defend it.
    Ceiling breaches - SWAT troops can breach the ceiling of the ‘Operations’ room and rappel down right into the thick of it! There are a few places where this can happen (it doesn't always).
      These dynamic elements will vary and change independently. This can be very desirable, as it will give you a large set of different combinations and improve the replayability of the level. For example, even if the fuse box is in the same location in two separate playthroughs, the positioning of the entrances and windows will change how the players approach the situation, which will help reduce level fatigue.
     

    The Operations Room. The Servers are kept in the room under the illuminated FBI logo. 
    The Quests
    There are four servers Hoxton must search through in the Operations Room. Between the searching of each server, Hoxton will need the player's assistance and send them on a “quest”. There are five different quests, though only three are selected and used in each playthrough. They can be selected in any order and combination. Each quest and its gameplay have been designed to have a slightly different flavor.
      Security Office - The next server happens to be heavily encrypted. You need to break into the Security Office, download the encryption keys and get them back to Hoxton.
    IT Department - The next server is missing and the log states it was taken to the IT Department for maintenance. You must locate the IT Department, find the missing server and bring it back to Hoxton.
    Archives - Hoxton finds a reference to some physical files kept in the archives. You need to go down to the basement, search through the archives and bring the paper files to Hoxton.
    Forensics - Hoxton learns that the FBI has evidence related to the traitor. Players need to break into the evidence locker, find the right piece of evidence and then scan it in the nearby laboratory for clues before returning to Hoxton.
    Director’s Office - Hoxton encounters some files on the next server that can only be accessed by gaining direct approval from the FBI Director. You must head to the director’s office and use his computer to approve all of Hoxton’s security clearance requests.
      What this means is that players won’t know exactly which “quests” they will tackle each time they play the mission, or in which order they will face them. As the difficulty slowly ramps up during the mission and the players’ supplies generally are lower towards the end, completing the same quest as either your first or last one can become quite a different experience, even though the quest itself doesn’t change that much. Allowing the quests to be arranged in any order and combination simply gives the mission a slightly different flow each time.
     

    The five quests, clockwise from top right: IT Department, Security Office, Archives, Forensics. Center: Director's Office
    The Combat Now, it’s about time we talked about the combat. It is essential for the replayability of a level that the combat isn’t static and that encounters vary between playthroughs. To solve this, Payday 2 has a spawning system that serves up dynamic enemy encounters. The system unburdens individual level designers and creates a consistent and tweakable way for the game to spawn enemies in all levels. For those of you who have played the Left 4 Dead games this may sound very familiar. The system isn’t completely automated and the level designer can control a few variables.
      Difficulty - The player selects the overall difficulty of a level before starting, but a designer can tweak the difficulty to a factor between 0 and 1. This can be adjusted at any point during the mission and can be tied to certain events.
    Spawn locations - A designer designates spawn locations manually. The designer can toggle spawn locations on and off, change how often they can be used to spawn enemies and which kind of enemies are allowed to spawn from them.
    Enemy Wave Mode - Police assaults occur regularly and this is generally handled by the system, but a designer can force a police assault or a complete break from them.
    Snipers/Harassers - The placement of snipers and so called harassers, regular SWAT troops who harass players from vantage points, is done manually. It is up to the designer to place them in challenging, but fair, positions and script logic which decides when and if they appear.
      What this all means is that while the spawning system does the heavy lifting and creates varied combat encounters, a designer can fine-tune the experience and still direct the combat somewhat. For example, in Hoxton Breakout the difficulty is slowly ramped up after each completed server, the spawn locations are continuously tweaked throughout the mission to make fights fair and when it is time to escape an endless police assault is forcefully triggered to increase the stakes!


    A dynamically spawned enemy squad moves towards the Payday gang.
    The keycard economy
    In Payday 2, keycards are single-use items that are occasionally used to open certain doors. In order to add depth and strategy to the level, I added something to this level which I like to call “the keycard economy”. In every playthrough, players can find 3-4 keycards which can be used, i.e. “spent”, on a variety of options like overriding doors to seal them off from enemies, unlocking rooms that contain precious resources or opening doors that lead to objectives. The value of the different options can change between playthroughs, depending on dynamic variables and which loadouts the players have. Since players can’t have all the options, they must choose wisely. This allows players to refine their strategy over the course of multiple playthroughs, adding to the level’s replayability.
      The little things We’ve discussed all the major dynamic elements of the level at this point, but it is worth mentioning that replayability also arises from smaller dynamic elements too. These smaller surprises can throw players off and force them to adapt accordingly. A good example can be found in the Security Office, where the police sometimes pumps in tear gas when players are trying to complete the objective inside. This forces players to leave the relative safety of the room and charge head first into the police forces which are surely waiting outside. Part of making a dynamic level should be to identify and implement these little game changers!
     

    Clockwise from top right: The Security Room fills with gas. A keycard has been used to seal a security door. An innocent keycard. A SWAT team rushing to thwart the payday gang.
    Discussion
    To summarize, the level we’ve looked at is about defending a location and completing short “quests”, with both activities changing in different ways between playthroughs. In addition to this variety, enemies are dynamically spawned, occasional surprises appear and players are able to learn and master the keycard economy over the course of multiple playthroughs. These dynamic elements, this variety between playthroughs, is what turns the level into a dynamic one.
      This level was made for Payday 2 and, as mentioned, dynamic levels will look a bit different depending on the game and its needs. The Left 4 Dead games have less emphasis on objectives and focus more on linear progression through a level, with dynamic enemies, items and minor path changes along the way. The Killing Floor games have arena levels that suit the game’s wave-based horde mode and these levels feature fairly simple dynamic elements: enemy and item spawning as well as the location of the weapon and item shop. The revived XCOM franchise uses levels which have designated areas or “slots” where different buildings and structures can fit in and shift the layout accordingly. The XCOM games also allow different missions to be played on the same level, enabling levels to provide even more gameplay mileage.
      The dynamic level design approach may fit these games, and others like them, but it is not suitable for all kinds of games and it definitely comes at a price. Since dynamic levels are designed to be replayable, heavily scripted story moments and set pieces may have to be deemphasized or removed outright. Playing through such sections may be thrilling once or twice, but they generally lose their appeal very quickly. Furthermore, some degree of polish is generally lost in the process of making dynamic levels. The fact that you are making an experience that can’t just happen “in one way” means you can’t necessarily polish, and control, every moment of gameplay to an insane standard, like you would expect in an Uncharted game for example. Additionally, an incredibly strong core gameplay loop is almost a requirement for a game with dynamic level design. Since the levels can’t be overly scripted, directed and set-piece heavy, the levels can’t compensate and “lift up” a slightly weaker core gameplay. Finally, one must also consider that creating dynamic elements in a level takes time, time which could be spent polishing or making more non-dynamic levels.
      These drawbacks must be weighed against the potential benefits. After all, the value of replayability should not be underestimated. As I mentioned in the beginning of the article, dynamic levels seem to be almost ideal for co-op games. Playing games together definitely adds something to the experience and this can help to compensate for some of the potential drawbacks like the lack of set-pieces. Adversarial multiplayer games, i.e. player vs player, don’t necessarily stand much to gain with the dynamic level design approach as the element of human unpredictability and challenge is usually enough to keep players engaged and entertained. By looking at XCOM, we can see that dynamic levels can be used to great effect in a game that isn't a shooter nor a cooperative one. And if we compare them to procedural levels, dynamic levels requires less sophisticated technology to create, but more human labor, and can offer something that feels a bit more handcrafted and unique. Ultimately, game makers need to look at the dynamic level design approach, its pros and cons, and ask themselves: is it the right approach for us?
  3. Like
    Evert reacted to leplubodeslapin for an article, Source Lighting Technical Analysis: Part Two   
    This is the second part of a technical analysis about Source Lighting, if you haven’t read the first part yet, you can find it here. 
    Last time, we studied the lightmaps, how they are baked and how VRAD handles the light travel through space. We ended the part 1 with an explanation of what the Constant-Linear-Quadratic Falloff system is, with a website that allows you to play with these variables and see how lighting falloff reacts to them. We will now continue with basic examples of things you can do with these variables. 
     
    Examples of application
    Constant falloff
    The simplest type of falloff is the 100% constant one. Whatever the distance is, the lighting has theoretically the same intensity. This is the kind of (non-)falloff used for the sun lighting, it is so far away from the map area, that light rays are supposed to be parallel and light keep its intensity. Constant falloff is also useful for fake lights, lights with a very low brightness but that are here to brighten up the area.
     
     

     
    Linear falloff

    Another type of falloff is the 100% linear one. With this configuration, light seems to be a bit artificial: it loses its intensity but goes way further than the 100% quadratic falloff. It can be very useful on spots, the lighting is smooth and powerful. Here is an example:
     

     
    Quadratic falloff

    This is the default configuration for any light entity in Hammer, following as we said before the classic Inverse-Square law (100% Quadratic Falloff). It is considered to be the most natural and realistic falloff configuration. The biggest issue is that it boosts the brightness so much on short distances, that you can easily obtain a big white spot. Here is an example, with a light distant of 16 units from a grey wall:

     
    This can also happen with linear falloff but it is worse with quadratic. Simple solutions exist for that, the most common is not to use a light entity but a light_spot entity that is oriented to the opposite direction from the wall/ceiling the light is fixed to. You can make the opening angle of your light_spot wider, with the inner and outer angle parameters (by default the outer one is 45°, increase that to a value of 85° for example). If needed, you can also add a light with low brightness to light the ceiling/wall a bit.

     
    50% & 0% FallOff
    A second light falloff system exists, overriding the constant-linear-quadratic system if used. The concept is much simpler, you have to configure only 2 distances:
    50 percent falloff distance: Distance at which light should fall off to 50% from its original intensity 0 percent fall off distance: Distance at which light should end. Well ... almost, it actually fall off to 1/256% from its original intensity, which is negligible. The good thing with this falloff system is that you can see the 2 spheres according to the 2 distances you have configured in Hammer. Just make sure to have this option activated: 

     
    Models lighting
    An appropriate section for models lighting is needed, because it differs from brush lighting (but the falloff stays the same). In any current game engine, lightmaps can be used on models, a specific UV unwrap is even made specifically for lightmaps. But on Source Engine 1 (except for Team Fortress 2) you cannot use lightmaps on models. 
    The standard lighting method for models is named Per-Vertex Lighting. This time, light won’t be lighting faces but vertices, all of the model’s vertices. For each one of them, VRAD will compute a color and brightness to apply. Finally, Source Engine will make a gradient between the vertices, for each triangle. For example:

    If we take a simple example of a sphere mesh with 2 different light entities next to it, we can see it working.
                
    With this lighting method, models will therefore be integrated in the environment with an appropriate lighting. The good thing is that, if a part of the model is in a dark area, and another part is in a bright area, the situation will be handled properly. The only requirement for this is that the mesh must have a sufficient level of detail in it; if there is a big plane area without additional vertices on it, the lighting details could be insufficient. 
    Here is an example of a simple square mesh with few triangles on the left and a lot on the right. With the complex mesh, the lighting is better, but more expensive. 

    If you need a complex mesh for your lighting, you don’t want your model to be too expensive, you have to find a balance. 
    Two VRAD commands are needed to make the Per-Vertex Lighting work:
    StaticPropLighting StaticPropPolys You have to add them here. You can find more information here.
    Another system exists, that is much cheaper and simpler. Instead of focusing on the lighting of all the vertices, the engine will only deal with the model’s origin. The result obtained in-game will be displayed on the whole model, using only what has been computed at the model’s origin location. This can be an issue if the model is big or supposed to be present in an area with lots of contrast in lighting. The best example for that is at the beginning of Half-Life 2 with trains entering and exiting tunnels. We can see the issue: the model is illuminated at the beginning, but when it enters the tunnel it suddenly turns dark. And this moment is when the train’s origin gets in the shadow. 
    This cheap lighting method will replace the per-vertex lighting for 3 types of models:
    For prop_dynamic or any kind of dynamic models used in the game (NPCs, weapon models in hand, any animated models...) For prop_physics For ANY MODEL USING A NORMAL MAP (vertex lighting causes issues with normal maps apparently), EVEN IF USED AS A PROP_STATIC
    The big problem with these models is their integration in the map, they won’t show any shadow and their lighting will be very flat and boring (because it’s the same used for the whole model). But hopefully there are 2 good things with this cheap lighting method. 
    First, the orientation from which comes light is taken into account, if blue light comes from one direction, therefore all the faces oriented toward this direction will be colored in blue. And if you have different lighting colorations/intensities coming from different sides of your model, they should appear in game. 
    Here is an example of a train model using a normal map with 2 lights on both side. If you look closely, you’ll see some blue lighting on the left, on faces that are supposed to be in the shadow of the blue light but are oriented toward the blue light.
     

     
    The second good thing is that there is still some kind of dynamic per-vertex lighting, but much simpler: it only works with light and light_spot entities (NOT with light_environment), and it just adds some light to the prop, it cannot cast any shadow (it only takes into account dynamically the distance between the light and the vertex). If we use again the high-poly plane mesh we had before as a prop_dynamic, being parented to a func_rotating that ... rotates. Light is dynamically lighting the vertices of the props. There is a limit of 3 dynamic lights per prop, it can’t handle more at the same time.

    And if you add a normal-map in your model’s texture, this cheap dynamic lighting works on it:

     
    Projected texture and Cascaded Shadows
    Few words to finish the study with dynamic lighting. Projected textures is a technology that appeared with Half-Life 2: Episode Two in 2007, it consists of a point-entity projecting a texture in the chosen direction, with a chosen opening angle (fov). The texture is projected with emissive properties (it can only increase the brightness, not lowering it) and it can generate shadows or not. The great thing with this technology is that it’s fully dynamic, the env_projectedtexture can move and/or aim at moving targets. This technology is used for example on flashlights in Source games. But as usual, there is also a drawback: most of the time you can only use only 1 projected texture at a time, modders can change this value quite easily but on Valve games it is always locked on 1. 

    The cascaded shadows system is only used on CS:GO. The concept is quite similar from a projected texture but it doesn’t increase the brightness, it only adds finer shadows. It is used for environment lighting, using much smaller luxels than for the lightmaps and it is fully dynamic. It starts from the tools/toolsskybox textures of the map and cast shadows if it meets any obstacle. Shadows from the lightmap are most of the time low resolution and the transition between a bright and a dark area is blurry and wide. Therefore, the cascaded shadow will be able to draw a clear shadow around the one from the lightmaps.

    When an object is too small to get a shadow in the lightmap, it will be visible thanks to the cascaded shadows. There are 3 levels of detail for cascaded shadows on Counter-Strike, you can configure the max distance at which the cascaded shadows will work in the env_cascade_light entity at the parameter Max Shadow Distance (by default it’s 400 units). The levels of detail will be distributed within this range, for example: 

    Since cascaded shadows and projected textures share some technology, you can’t use them both at the same time.
     
    Conclusion
    I really hope you have found this article interesting and learned at least few things from it. I believe most of these informations are not the easiest to find and it’s always good to know how your tools work, to understand their behavior. Source Engine 1 is old and its technologies might not be used anymore in the future, more powerful and credible technologies are released frequently but it’s always good to know your classics, right? 
    I would like to thank Thrik and ’RZL for supporting me to write this article, and long live the Core!
    // Written by Sylvain "Leplubodeslapin" Menguy
    Additional commands for fun
    Mat_luxels 1                              // Allows you to see the lightmaps grids Mat_fullbright 1                         // Disables all the lighting (= fullbright). On CS:GO, cascaded shadows stay and you should delete them as well (cf next command) Ent_fire env_cascade_light kill  // KILL WITH FIRE the cascade shadows entity Mat_drawgray 1                        // Replace all the textures with a monochrome grey texture, useful to work on your lighting  Mat_fullbright 2                         // Alternative to Mat_drawgray 1 Bonus:
    Mat_showlowresimage 1           // Minecraft mode
  4. Like
    Evert reacted to Rick_D for an article, Making Agency, the popular CS:GO map   
    What is Agency?
    Just in case you have never heard of Counter Strike: Global Offensive, it's a hugely popular online FPS, successor to Counter Strike: Source and the original Counter Strike. The original came out in 1999 and the core gameplay has remained almost unchanged. Players are split into two teams and challenge each other in various game modes such as Bomb Defusal (one team has to plant and detonate the bomb while the other tries to stop them) and Hostage Rescue (one team must rescue the hostages whilst the other attempts to prevent that). The Bomb Defusal mode is by far the most popular, with maps designed with such detail that players can predict down to the second when another player is due to arrive in a certain area of the level. It's also the only mode played in competitive events and for huge prize money.
    This leaves the poor Hostage Rescue mode sitting on the sidelines twiddling it's thumbs and feeling a little rejected. In part this is because the Hostage Rescue mode is far more of a roleplaying experience, often with very poor odds of success for the team tasked with doing the rescuing. Often the levels are designed in such a way that the defending team has a large positional advantage, where simply staying-put will give them a good chance of winning.
    That's where we can start talking about Agency. Agency is a Hostage Rescue level, created as a collaboration between level designer Patrick Murphy, and myself doing the art. The basic idea being that Hostage Rescue could be just as precise and exciting as Bomb Defusal. It's been included in three official releases from the games creator, Valve, as part of their community level packs: Operation Bravo, Operation Phoenix and Operation Bloodhound. Phoenix being a community-voted choice, which was especially great to see that players enjoyed the style of gameplay and visuals that Agency brought with it.
    In this article I will go over the process of creating the art, from props to set dressing, texture creation and lighting, while maintaining a visually pleasing aesthetic and serving to enhance the gameplay. This isn't a postmortem but rather a walk-through of the various stages, hopefully to give some ideas to others, with lessons learned both positive and negative.

    Iteration from Whitebox to Final
    Starting out you should always have an idea of what you're going to create, even if it is quite vague, as it'll point you in the right direction for both creating architectural spaces and letting your imagination fill in the blanks as you build the basic shapes of the level. We knew we were going to build an office space, but style was leaning towards an older government building with red bricks and musty wood. As I started to put in some basic textures we decided it felt too bland, and similar to other levels in the game. In order to stand out and create something really interesting and intriguing that would entice players to want to explore the level we decided to modernize the space and use white as the primary colour - this would help players see each other more easily and provide a striking visual setting it apart from other levels.
    "Modern Office" is not exactly a style that has a single look, if you search for images you'll get back a lot of contrasting designs and ideas, trying to put every single one of those into a level would create a visual mess with no consistency. It's important to choose the right references for what you are building, something that looks cool in a single image or from a specific location might not fit into the theme of the level, and in a worst-case-scenario it might actually start to detract from the level as a whole. Trying to cram in as much content as possible simply makes your level feel less unified and jarring.
    Unfortunately when you are presented with so many fantastic designs and ideas it can be hard to pick out what is important. After settling on the location: a modern advertising agency's office, I broke down the needs of the level into a few different categories:
    Area Specific General Use Overall Theme The Area Specific content is "hero assets" for each location in the level. These are the things that help the player tell different areas apart from each other, a reception desk, a kitchen, a bathroom, etc. Assets that won't be used anywhere else except in their specific location.
     

    Examples of Area Specific Content

    The General Use content is the backbone of the building, it's wall sockets, ventilation tubes, sprinklers, desks and chairs. The things that could be used anywhere and would blend in to the background and not stand out unless you were specifically looking for them.
     

    Examples of General Use Content

    The Overall Theme content is what sells the theme of the level to players, advertising boards, company logos, large art installations and so on. These can be used everywhere but sparingly and should only be used as a subtle reminder to the player of where they are thematically. They shouldn't detract from the Area Specific content but should stand out more than the General Use content. This came in the form of abstract paintings, corporate logos, rotating advertisement panels and so on - things that would subtly tie the level together.
    Once these categories were laid out, searching through reference images became much simpler as you know what you need and only have to find an interesting design or detail that enhances a specific category.
    This isn't to say that everything was completely planned out or that development was flawless. Sticking to a plan only works until you open the editor, and if you try to force something you'll end up frustrated when it consistently fails to work. As an example we originally had the level set on the ground floor of a tall skyscraper. I spent a few weeks working on content for the ground but never really getting it to feel right within the theme of the level: the contrast between a dirty exterior street section and a spotless interior didn't feel right for the level, and felt a little too similar to another Counter Strike level. Patrick played around with some ideas and tried something I was afraid of: simply deleting everything I had done on the outside and adding an epic city vista. Instantly it felt right. The important thing to take away from this is that just because you have worked on something doesn't mean it's the right thing to be working on, and that getting input from other people with different ideas can vastly improve what you are working on.
     

    The first mockup of Agency's rooftop exterior
     

    The same space after an art pass

    Another incredibly important thing I realised is making use of modular assets. If you are going to duplicate something in your particular modelling software you should ask yourself: is this efficient? Chances are you're just making things harder to change later and locking yourself into a particular shape; eg: a walkway has a railing around it, you model the entire railing as a single object. Now if you need to change that walkway a month later you're going to have to go back and change your railing model. It's better to create a smaller tiling mesh that can be used multiple times, as often you'll find you can use that model in other areas and in different ways than you had initially intended. You're simply applying the concept of tiling textures to models, and in the process saving yourself a lot of time.

    A Believable Clean Art Style
    Creating a clean environment can often be more difficult and time consuming than a very dirty and cluttered one, simply because any mistakes are magnified by the lack of other objects to disguise them. A room with a single chair in the middle is going to end up with the focus being on that chair, if you fill that room with a hundred chairs you're going to be less concerned with the details of the chair and more worried about why someone would fill a room with a hundred chairs.
    In the modern office setting of Agency it would have made little sense to fill it with props and clutter, but a large empty space would just feel unfinished. A delicate balance of larger architectural shapes and smaller objects was needed. I like to think of this as functional art: it serves a purpose in the lore of the game world. Window and door frames, electrical sockets, thermostats and card swipes along with the maintenance apparatus of ventilation systems. These are the general use objects mentioned earlier, they fill out space and prevent an empty wall or ceiling from actually looking empty and at the same time they contribute to the believability of the level. It's important to think of the infrastructure of the building when placing these assets - if a wall has an air vent on it then the wall needs to be thick enough to support the ventilation pipes that feed it, Card swiping mechanisms need to be placed near doors at the correct height, electrical sockets should be placed logically in areas where they would be of use to the fictional inhabitants of the level and so on.
     

    Several examples of functional art details

    One of the most important things to do right when creating clean environments is to get the most out of the materials. It's not possible to cover every surface in dirt or decals, so the surfaces themselves become your way of showing detail.
    For Agency this was achieved by making liberal use of the phong shading techniques in the Source engine for models, and cubemaps for world textures. Almost all models in the level have some amount of phong shading, and although it doesn't produce a completely physically accurate result it can be used to create materials and surfaces that look relatively accurate. Simply by increasing or decreasing the intensity of the phong amount allowed for a vast majority of the levels surfaces to be rendered accurately. As I didn't need to have a lot of noisy detail in the materials due to the clean style I simply used a small phong texture as a mask for 75% of the models and let the lighting and general shapes of the models do the rest of the work.
     

    Simple phong shading to mimic real world materials

    As most of the surfaces had a single layer of material, ie paint or coloured metal, the phong shading could be completely even without breaking the illusion; however some of the dirtier surfaces such ventilation tubes and water pipes had several layers: a painted metal surface with area peeled away to reveal with metal underneath or a layer of dust. These had specific masks that would enhance the different materials, and showing wear and tear in the background assets added an extra layer of depth without compromising the clean style.
    Most of these textures were created with dDo, an excellent tool for quickly creating textures. I generally started with quite a dirty texture preset and toned down the details and noise until they were barely perceptible surface imperfections.
    Agency features probably close to 95% custom art, and that's a lot of work for a single person. Using dDo allowed me to make a lot of content relatively quickly, and kept it all visually consistent.
    The process of creating the assets with dDo was quite simple: first I modeled the basic ingame asset, then did a very quick and dirty placement of edge loops that allowed me to smooth the mesh and get a workable high poly. A very rough normal map was baked (along with a more solid ambient occlusion map), this rough normal map would never make it into the game, it was used purely for texturing with dDo. This rough-and-dirty technique was mostly used on the more general purpose assets that nobody would spend a lot of time looking at. For the objects that were in high traffic areas or that required finer detail a more robust normal map was created.
    Tiling textures used throughout the world were photo-sourced and tiled in Photoshop. A few examples worth pointing out are the plaster wall textures and the marble floors:
     


    The image above shows the ingame result, the diffuse texture, and the normal map of the standard plaster that is used throughout the level. The normal map was authored at 1024x1024 compared to the diffuse texture which was 512x512. I created several colour variations of the diffuse texture and for a very plain surface using a 1024x1024 diffuse didn't make much sense. The final touch was to add a subtle cubemap effect to bring out the normal map and add interesting coloured reflections in various areas.
     


    Another example is a marble floor used throughout the level. The normal map is unrealistic in that it portrays an uneven bumpy surface when in fact it is more likely to be uniformly flat. However to break up the reflections and add some visual interest to such a large and empty area I added a subtle bumpy normal map which warps the reflections, but is subtle enough that it doesn't get picked up by the lighting and actually appear like a lumpy mess.
    Good shading only gets you part of the way there, however. A poorly scaled model can break immersion instantly, especially when you are trying to create a believable real-world environment. There are tried-and-true metrics for Counter Strike so having a base to work from helped immensely, but these only give you a good starting point or a bounding box for your object. It's important to study real world reference and make sure your object is proportional to the world around it and also to itself. A unit in Hammer is an inch, so having wood that's 2 units thick, or a doorway that is 1.5m wide quickly makes things look wrong.

    Working with Designer Blockouts, and not Destroying Gameplay
    Agency was a collaboration, with Patrick doing the design work and me doing the visuals, this meant there was a lot of potential for overlap and working on the same areas, the potential for breaking things was huge.
    Often when you create things as an individual you don't have to worry about version control or stepping on someone else's toes, however when you work with other people either for pleasure or business you, as an artist, need to change your mindset. You are not creating a portfolio piece but rather something functional that has to withstand hundreds of hours of real people playing it.
    Your first role is to support the designer, and this benefits you as well. By creating the basic structures of the level: doorways, window frames, stairs, railings, cover objects etc, you are allowing them to work with the final assets and tweak gameplay according to those assets. Nothing needs to be finalized instantly, it's better to provide a rough mockup of the intended asset so the designer can play around with it and give feedback on the shape, size and silhouette. Once you are both confident it's going to work they can populate the level with these assets which saves you time in the long run, and once you finalize the model and textures they are going to be updated across the entire level without having to manually replace assets.
    It can be difficult to determine exactly when you should start an art pass, especially when a level is constantly evolving. Rather than sitting idly by whilst Patrick was ironing out the design of the level I started on the creation of a few visual test levels to explore materials, lighting and modular assets. Once the first iterations of Agency were created, with rough shapes for important cover and controlling lines-of-sight. I went in and created an art pass and altered many of these original gameplay ideas, simply experimenting with different shapes and designs for the rooms. We had a constant dialogue and never considered something finalized just because it was finished. Playtests would determine whether an idea was valid or not in a way that speculation can only hope for. The most important lesson learned during this process of constant iteration was that work is very rarely wasted, and it is far more important to stay true to a gameplay ideal than to have an area that looks interesting in a screenshot but utterly fails when players get their hands on it. A box is a box is a box, it is down to you as an artist to imagine how that box can be interpreted within the context of the environment.
     

    Initial art pass ideas for the central area (above) versus the end result (below)
     

    Initial art pass ideas for the reception (above) versus the end result (below)
     

    Initial art pass ideas for a hostage (above) versus the end result (below)

    Lighting
    An important part of any environment is the lighting. Too contrasted and moody and it becomes hard to identify players, too bright and monotone and it becomes boring and a strain on the eyes. For Agency I used a series of instanced lighting setups: a model to visualise the light source, a spot light to direct the light, and a sprite or light cone to add a visual effect around the light. Each light setup was unique to the type of model used for the actual light source, ie: all spotlights were identical, all fluorescent lights were identical etc. This meant I could change a single light and have the others update automatically, and always get an accurate result.
    Then it was just a case of placing these different types of lights where they logically made sense in the environment, and if an area was too dark an appropriate light source was added, and if an area was too bright lights could be moved around or removed entirely. This made it quite easy to light as everything was guided by reality, which has plenty of reference material, and had the side effect of helping to make the environment more believable. By using various colours on the floor and walls I could direct lights towards them and take advantage of the Source engine's excellent radiosity and spread interesting colours to nearby surfaces.
    In many areas the ceiling was opened up to reveal the sky and to let natural sunlight into the interior spaces, this was done to provide contrast to the electrical lights and to get extra radiosity bounces into the environment. Some areas had lights removed or toned down to allow other more important gameplay areas to stand out, for example the image below shows how the corridor here was darkened both by using darker textures and by using restrained lighting to make the room in the distance appear brighter as this is an area that enemy players will appear from.
     


    This could have been taken even further by possibly using emergency exit signs to add hints of colour to important gameplay areas and chokepoints. A consistent lighting language would have helped guide players during the first few times playing the level. There are some large open spaces that would have benefited from some coloured screens or lighting panels, or possibly making some of the larger glass surfaces tinted, to add a little extra colour and prevent such a monotone look whilst not being over-bearing or detracting from the realistic style of lighting I was aiming for.

    Final thoughts
    During the course of developing Agency I had a chance to learn a few things and come out the other end a, hopefully, better artist.
    So, what went well?
    The iteration process never had any hiccups, by using modular content and being prepared to discard ideas and art styles that weren't working we ended up with a better level. If we had tried to force the original idea of a ground-level government office we would have ended up with a completely different level, complete with underground parking lots and elevator shafts. Exciting stuff!
    The power of iteration cannot be understated, and understanding that a mockup or a blockout of a level is simply a temporary phase that doesn't represent the end result. Areas changed drastically between versions, sometimes due to design requirements, and sometimes of shifts in art style; but each version was better than the last, more refined and polished.
    What went less well?
    In direct contrast to the statement above, sometimes the iteration interfered with more important tasks. I got stuck on areas trying to get them to work instead of letting them sit for a while and returning to them later. I tried to force an idea for the exterior part of the level and it never felt right and consumed way too much time, when all it took was getting some outside perspective. Luckily during the process I learnt to trust designers when it comes to art, just because they might not build high poly meshes doesn't mean they aren't artistic.
    Another problem was building too much content completely unique for an area which meant when we inevitably changed things it became time consuming to shift assets around, and makes it less easy for others to re-use that content without creating an almost replica of the area it was designed for. These unique assets helped sell the realism of the level but made them harder to work with.
    Hopefully this has been interesting and insightful!
  5. Like
    Evert reacted to Thrik for an article, Introducing MapCore's new logo and store   
    Designed by professional designer Arthur de Padua (AKA Thurnip), the new logo was developed over a period of many months and incorporates some of the successful themes that came up during the logo design contest we had some time ago. Unlike the existing logo which only existed as a low-resolution render, this one is perfectly crisp and comes in numerous formats suitable for print — allowing us to finally offer high-quality merchandise.

    So, head over to the MapCore store if you want to show your MapCorian allegiance in public! All items come as a 'Regular Edition' (no profit for MapCore) and 'Donation Edition' (£5 profit that goes towards MapCore hosting/development costs).

    We're currently offering a small but carefully designed selection of products. Once we make sure everything's running OK and we don't need to change vendor for whatever reason, more products will be added. We'll also soon be adding a way for you to donate while receiving a small token of appreciation (e.g. a sticker that can be bought for £5, £10, or £20) for those who want to support us but don't necessarily need or want a T-shirt, etc.

    If you buy anything, be sure to post some photos for us to look at! I have some orders on the way, so will create a thread for such snaps if nobody else beats me to it. If you'd love to buy something but the item you want isn't available, don't hesitate to leave a comment or get in touch with me — I'm happy to build up the products based upon what people want.
×
×
  • Create New...