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.
This article is the first installment in a three-part article that looks at the considerations for creating a single-player combat space, using a walkthrough of the first battle in ‘Killzone Mercenary’ as a working example.
Creating a Single-Player Combat Space Part 1
This article will explain how to create a combat space for a single-player campaign, using my work on ‘Killzone Mercenary’ (hereon referred to as KZM) as an example. There is already a fair amount of literature on the different methods you can use for creating a combat encounter, but I felt that none of it really discussed how to arrange the layout in closer detail, nor did they discuss where the different elements were appropriate. In my early work I tried to jam in all the concepts for encounter design without fully understanding how they affected the player’s experience. As strange as it sounds, I discovered there were times when it was better to restrict the number of elements being used to provide a much more focused and coherent experience; sometimes less is more. I will take you through an example to explain what I mean and how this can be the case.
I will use the very first combat arena in KZM as it’s a small encounter where I can explain in depth what goes into even the most basic combat space. This encounter is a fight against assault troopers who are trying to stop the player from escaping the building and reaching the objective building; the ‘Halls of Justice’. I designed bigger encounters that featured many flanking opportunities and complex circular navigability but focusing on a simple encounter allows me to explain certain techniques in detail and where I purposely removed some elements to balance the difficulty and give the player different experiences.
First of all I will explain two important aspects that must be considered for combat creation; AI metrics and weapon choice. I will then take you through a step by step walkthrough of this first encounter explaining in detail the reasons how it was designed and constructed for optimum player experience.
Metrics
The design mantra ‘form follows function’ should be the basis when creating an arena layout; that is that the arrangement of geometry should derive from its purpose. The arrangement should support the function not only of the style of experience you want to create (is it a tight corridor section with close quarters combat or an open space with multiple routes and options, for example) but it should also support the main element that makes up the combat encounter; the enemy AI.
When considering the layout for the AI or non-player characters (NPCs) that will populate your environment you have to consider their metrics. These are the numerical values for how the NPCs move around and use the environment and the differences between various NPC enemy classes. This isn’t something people tend to talk about and so it can be easily forgotten or missed, yet it directly affects how your enemies will move and react.
For example, in KZM the standard enemy NPC class were the Assault Troopers. These soldiers could be given patrols and animations to perform whilst they were in an ‘unalerted’ state, just like every other enemy class. However, when they were in an alerted state their behavior changed so that they used cover points to move around the combat space. The maximum distance between cover points that an assault trooper would move was 10 meters. This meant that any cover point that was further away would not be considered, so we needed to make sure when creating combat spaces which used assault troopers that there were enough cover islands so they could move around. If there weren’t, the assault troopers would just stay in the same spot and could risk looking less intelligent.
The assault troopers also tried to maintain a distance of 15m whilst they were trading shots with the player. The behavior was that if the player got closer than this range, but not so close that they were in melee combat distance (5m), the assault troopers would retreat to this mid-range distance of 15m. They would also never choose a cover position that was closer than 15m to the player, so when we created combat spaces we had to make sure that there was enough variety of cover positions in the >15m range.
For the production of KZM we used the ‘Killzone 3’ engine and modified it for the PS Vita. In ‘Killzone 3’ the assault troopers picked their cover within a range that was further than 25m from the player, but we discovered that this was too great a distance for the enemy to still be clear and readable on the PS Vita screen. In our modified version of the KZ engine we had to reduce the combat distance to 15m, which meant that the original combat spaces we had created using the ‘Killzone 3’ metrics also needed adjusting in order for the NPCs to still work. It is an unfortunate truth that the game metrics, be it for the AI or otherwise, can change within a game’s development, which means that your combat arenas will also need to be adjusted.
Weapon Consideration
The metrics for both the player and enemy weapons were also considered. As this is the start of the game we can be more certain that the player is using the default starting weapons, at least on their first playthrough, before they have earned enough credits to buy a new arsenal. Therefore, the combat distances of enemy placement were considered to be comfortably within range for the player’s assault rifle.
The enemy assault trooper archetype used assault rifles that were balanced to have a short range of <10m, and a long range of >20m. This meant that their behavior was to try and keep the player within these ranges and would thus move around the environment to try and maintain this. This was important to consider when building the environment so we could determine the amount of movement the troopers were likely to perform. This is important for balancing difficulty as a moving target is harder to hit.
Foreshadowing
As this was the opening of the game, we wanted to make it compelling in order to grasp and hold the player’s attention; we wanted to start with a bang. If the first lot of encounters in the game only included assault troopers with nothing else to differentiate them it may not have been so compelling. Therefore, we decided to include a significant Killzone enemy vehicle; the Helghast Dropship. Of course it would have been far too difficult to fight a Dropship at this point in the game, so instead it was used as an impressive introduction of enemies into the arena using the rappel ropes from the ship itself.
Using the Dropship at the end of the encounter, it was important to foreshadow its existence prior to its introduction. The level’s opening cut scene introduces the buddy character, Ivanov, and the narrative that he and the player are infiltrating the building whilst trying to avoid the searching eye of the Dropship.
The foreshadowing of the Helghast Dropship
Once the player has control they make their way up a flight of stairs learning how the movement works and feels whilst being in a safe environment. Once at the top of the stairs they enter through a door where they are introduced to the new melee attack which utilizes the touch screen on the PS Vita.
First Wave
After a successful melee attack the player enters through the door to the first combat area. The composition shows the exit of the arena in the top left third of the frame. Central to the player’s view is where the first pair of enemies enter from, ensuring that their arrival is not missed.
The exit to the arena is in the top left section of the opening composition
Starting on the level above, the two assault troopers vault down into the gameplay space, to give their presence a more dramatic opening than merely walking in through a door. Their animation and movement also ensures that they catch the player’s eye if they aren’t looking in the desired direction. These vault down animations were 4m high, the standard height for a room in KZM, which meant this was a metric we had for the balcony and floor above.
Two assault troopers drop into the environment from the level above
Once the assault troopers had landed in the arena they became a lot less mobile than their standard behavior so that they were easier to shoot because, as previously mentioned, a moving target is harder to hit. As this is the very first section of combat the player encounters in the game it was important to ensure that it was easy to get to grips with.
None of the enemies were waypoint/navmesh restricted to certain areas in order to limit their movement as this could potentially lead to NPCs not behaving correctly under differing circumstances. In fact, there were only a very select few instances where we waypoint/navmesh restricted any characters in the whole of KZM; we instead crafted the environments to support the behavior we wanted from the NPCs. This was important for consistency; if you restrict areas and zones for the AI then they won’t behave consistently with what the player has learnt. This would lead to the player not being able to predict their behavior and therefore won’t be able to plan how to attack effectively.
Here, in this first section, the two assault troopers took cover at two upright pillars of high cover and an overturned sofa of low cover. They didn’t tend to venture further into the environment unless the player had for some reason retreated to the edges of the level. The reason they wouldn’t move and advance on, or flank the player was because the other cover options in front of them were within 15m of where the player was likely to be stood. This caused them to be more static and thus easier targets to allow the player to get to grips with the shooting mechanics.
I also chose to mainly use higher cover here so that when the enemies lean out of cover their shooting positions allowed the player to shoot their full body, which was a bigger target than when they poked their heads over the top of the low cover positions.
Low cover positions are great for seeing the enemies move around and change their positions, as the tops of their helmets are visible over the top of the cover. Enemies are much harder to track when they use high cover as it breaks line of sight to them, so this is usually the harder option. However, as they have restricted cover positions and weren’t moving around in this specific situation, it was the best option to use for less difficulty.
First Combat Front
A ‘front’ is the perceived line or boundary that faces the enemy and is the nearest position which combat should be engaged from. The ‘fronts’ used here create boundaries between the two sides; a front for the player and the buddy character and an opposing front for the two assault troopers. This was the simplest setup to start the player off with and it only required two sets of cover points as I didn’t want to encourage the enemy to flank the player at this stage. This section of the encounter only needed these few pieces of cover (in the image below) in order to work and the other pieces of cover were actually for further waves of combat.
/r/GlobalOffensive and Mapcore are teaming up to grow Counter-Strike: Global Offensive’s mapping community!
Check out the reddit thread for this contest »
The Big Reveal
We’re hosting a map-making contest for original, competitive 5v5 bomb defusal maps AND competitively-minded hostage maps, open exclusively to mappers who have not yet had their work featured in a Valve Operation!
Older projects are fair game: now’s the perfect time to polish up that map you’ve been working on but never got around to finishing. Experienced Mapcore judges and prominent members of the Counter-Strike community such as Sadokist, Moses, DDK, James Bardolph, and Anders Blume will be weighing in – but only one map can win it all.
Helpful Playtesting
Every week for the length of the contest, eligible maps will be playtested during /r/GlobalOffensive community nights according to a sign-up schedule. Slots on this schedule will be filled on a first-come, first-serve basis following an approval process, but we will try our best to accommodate everyone at least once. However, because it’s impossible to guarantee that all contest entries will have the chance to be playtested, /r/GlobalOffensive playtesting is a supplemental, helpful tool which will have no bearing whatsoever on contest judging.
You can register for a playtesting slot here. Remember -- playtesting registration is first-come, first-serve!
Enter Your Level
To officially enter your level into this contest, post a WIP thread with a link to your level’s Steam Workshop page in Mapcore’s official event forum.
Posting a WIP thread with a link to your level’s Steam workshop page constitutes your official entry into the contest, however you don’t need to do both at the same time. In other words, you can post your WIP thread and then update it later with your workshop link if you’re not ready to go right away. You can also feel free to continue updating your workshop level after you’ve posted your workshop link – contest entries will not be judged until after the submission deadline.
The Deadline
Your level must be submitted to Mapcore by August 31st, 2015 at midnight Pacific Standard Time (PST).
Our panel of judges will then select four finalist levels based on the following criteria: Fun factor Visual/thematic presentation (graphics) Overall polish Grand Prize Deadline After the top four maps have been announced, /r/GlobalOffensive users will put them to the test! Once all four finalist maps have been tested, mappers will have two weeks to revise their work based on community feedback. After those two weeks, an official Grand Prize Winning Map will be chosen!
Contest Calendar
Our Goal
The goal of this event is to raise awareness about Mapcore's incredible level design community and the incredibly useful playtesting capabilities of /r/GlobalOffensive. Both Mapcore and /r/GlobalOffensive are free resources available to all mappers. To date, Mapcore users are responsible for creating more than 70% of Valve Operation levels. Mapcore’s staff are unpaid volunteers, and do not personally profit in any way from additional traffic to the site.
Prizes
Of course, it wouldn’t be a contest without a reward… In addition to the helpful feedback and free publicity that CS:GO mappers will receive by participating in this event, each finalist will also receive: Eternal Bragging Rights™ and a showcase on Mapcore (where their level will be highly visible to industry-veteran game developers and the rest of the community) A monetary prize ($1000 + Mapcore swag for first place; $400 for second place; $200 for third place; $100 and Mapcore swag for fourth place) The top-finishing map will also be played in a competitive show-match casted and streamed by goRGNtv, for all to watch and enjoy! *NEW* CEVO has generously agreed to host the winning map in their PUG rotations for one month! *NEW* Added $1,000 to prize pool thanks to Gamebanana.com and EGO DEATH (gun skin creator) *NEW* Valve prizes! Top 4 will receive 1. Signed CS:GO poster 2. CS:GO Lanyard 3. CS:GO Vinyl Sticker
First place will receive a CS:GO prize pack: 1. Signed CS:GO poster 2. CS:GO Lanyard 3. CS:GO Vinyl Sticker 4. CS:GO SteelSeries Kana Mouse
This is your big chance -- get to it! Good luck, mappers!
Additional Rules Remakes of older maps are NOT allowed. All works must be original to you and their layouts must not have appeared in any prior versions of Counter-Strike. Custom artwork is allowed and encouraged, but must meet workshop guidelines. Collaborations are allowed and encouraged. Any contest winnings arising from a collaboration will be split in accordance with the collaborators' mutual agreement.
Judging Procedure Mapcore staff will rate their top four maps of the contest, results will be tallied and all votes given equal weight. Some time later, the judges and guest judges will rate the top four finalist maps and results will be tallied, with all votes given equal weight. Guest judges will be asked to act as tie-breakers in the event of any ties in the voting. Mapcore Judges Jason “General Vivi” Mojica -- Creator of "Rose Iron" Skin (Overkill Software) Patrick "Puddy" Murphy -- Creator of CS_AGENCY (Overkill Software) RZL (Independent) -- Creator of DE_RESORT Shawn “FMPONE” Snelling (Independent) Johnny “Sprony” van Spronsen (Journalist)
Guest Judges Matt "Sadokist" Trivett -- @Sadokist Jason “Moses” O’Toole -- @JmosesOT Daniel "DDK" Kapadia -- @followddk James Bardolph -- @jamesbardolph Anders Blume -- @OnFireAnders
--- Our Thanks to EGO DEATH (Steam Workshop author)
Andre Valera reacted to General Vivi for an article, Designing Highly Replayable Stealth Levels for Payday 2