El Moroes reacted to Radu for an article, 2018: Mapcore's Year in Review
Keeping with tradition, I'd say it's about time we took a look at what our community has achieved throughout the year. If last time I was saying how 2017 was a year of immense growth, then 2018 was surely one of significant change. And it hasn't been without its troubles and anxious moments. No change ever is, but I believe it to be for the best. We've seen some of our friends become parents, change work fields or get their first job in the industry. We've even seen a few pursue their dream projects. And for that, we have to applaud them. It takes courage to keep moving forward and to realise when it's time for something new. In the meantime, I hope this article inspires you and I wish everyone
2018: Mapcore's Year in Review
SteamVR - Gulping Goat Space Farm
by @Steve, @marnamai, @The Horse Strangler, @Sersch and others at Scraggy Rascal Studios
produced in collaboration with Valve
"Scraggy Rascal has been working with Valve to create all new SteamVR content, we've been given a lot of liberty to create these locations. Our goal was to create interesting and fun locations for the player to explore. These projects, over the last couple months, have been a crash course in Source 2,VR, project management, delivering within deadlines, working together as a team and personal growth. It has been an invaluable experience and great opportunity ... and we're just getting started!" - marnamai
Darksiders III - Art
by @The Horse Strangler and others at Gunfire Games
"Probably one of the biggest challenges the artists and designers faced on Darksiders 3 was working with both a platforming and fully connected streamed world. This meant that everything exists all the time. While we streamed levels in and out, areas couldn't intersect and we couldn't do the classic "Small exterior, big interior" swap. This was especially challenging because of how much verticality our design must support. We had a few "vistas", but for the most part every aspect of the level was accessible. If you can see it, you will likely be able to get there, jump on it, fight around it, etc. Fury, the main playable character can double jump, swing, float, glide and even rocket jump over 10 meters high. Personally for me it completely changed how I looked at art filling up a space. Every single mesh we placed impacted design. Art was design, and design was art." - The Horse Strangler
"Europa is a relaxing narrative experience. The goal with this game is to offer just enough challenge that its rewarding to get from one area to the other for more than just the visuals by using environmental hazards, platforming sequences and light puzzles that you can beat by exploring.The game is split into linear sections and wider areas, that's at the core of the game and as you play, you keep improving your characters moving ability, which will further exploration and give you the ability to solve newer light puzzles. There's none of the typical character upgrading systems, rather, the levels will offer the incremental challenges and the sense of progression. Europa's main focus lies in environmental storytelling and immersing the player in it's universe with passive storytelling, evoking awe and bliss with colorful watercolor-like art and music." - Helder Pinto
Counter-Strike: Global Offensive - Turnpike
"For a while the "Highway Restaurant" theme has been sitting in my little Concepts.txt file. When the Wingman Contest was announced, it felt like the perfect opportunity to turn this idea into a map, as its relatively small size would be fitting for the Wingman gamemode. The casual nature of Wingman made me add some elements that I would not normally add to, let's say, a Defusal map, like the TF2-esque team color coding (albeit subtle), the moving vehicles and the silly bomb target. Additionally, since the playable space is (almost) completely indoors, making it nighttime felt right, as it both emphasizes the interiors and makes for an atmospheric blorange background." - Squad
Dying Light - A New Hope
"A full-fledged custom single player campaign that ties in to the original story of the main game. It will see the main protagonist, Kyle Crane,leaving the City for the countryside to search for a specific elusive medicinal herb and bring it back to Dr. Camden who believes it could be the cure to the Harran Virus. This campaign is a one man show as I’m doing everything myself: level design, environment art/detailing, story creation, scripting/quest creation, custom dialog, custom audio, custom materials/textures, custom foliage systems, custom brushes for terrain painting/sculpting, lighting, manual nav mesh tuning, scripted NPCs…" - will2k
by @General Vivi and Michael Voeller
"Prodeus is the first person shooter of old, re-imagined using modern rendering techniques. Oh, and tons of blood, gore, and secrets. Creating Prodeus has meant a lot to us over the last year. It feels great to finally be doing something for ourselves. It can be pretty ambitious at times since there are just two of us, but I’m confident we can pull it off. Keep an eye out for the end of February for a big announcement." - General Vivi
Counter-Strike: Global Offensive - Ruby
"When I was on vacation in Portugal years ago I was so impressed by the city Lisbon that I really wanted to build a map that has the same vibe. At the time I was already working on different projects so I decided whenever I got enough time to work on a map this size I would go back. So early 2017 the moment was finally there, I went back to Lisbon to shoot (~2000) reference photos then made a list of things that are iconic for Lisbon and started working on Ruby. Adding a lot of height differation, warm colors, tile patterns and ofcourse trams was essentiental to get the Lisbon vibe." - catfood
by @dux, @PogoP and others at Unknown Worlds Entertainment
"A mix of Survival, story, mystery, resource gathering, base building with some accidental horror and plenty of deep, deep water. We had not long finished up with Natural Selection 2 and were hungry to develop a different kind of game. During development we were (and still are) a small team but the game kept getting bigger and grew into something far larger in scope than originally planned. So we soon realised that what we had could be turned into something really unique if we put our heads down and just cranked on it." - dux
Unreal Tournament 4 - Chamber
"I used Halo and Warframe artstyle as a reference. The goal of this project was to make fun and cool looking map with 100% custom art that is 100 mb in file size. To achieve that I used several advanced techniques such as custom vertex normals, deferred mesh decals, no bake, tiling base materials and masks. There are basically 5 or so texture maps used in the entire map, most of the filesize space was taken by lightmaps. I learned a lot doing this project in terms of composition, art direction and optimization. Hope you enjoy this map as much as I do!" - Ubuska
Counter-Strike: Global Offensive - Pitstop
by @Quotingmc and Quadratic
"It is not often that CS: GO receives a new game-mode, especially one as competitively focused as Wingman. I was understandably pleased at the announcement of the 2018 CSMapMakers contest for the mode. Pitstop was my entry where I set out to create a thematically bold centre piece for my portfolio. With the help of my teammate Quadratic and support from multiple Mapcore members, I learnt a lot about taking a level from a simple blockout to completion; I can say for certain I’m thrilled with the end result!" - Quoting
Black Mesa - Xen
by @JeanPaul, Adam Engels and others at Crowbar Collective
"While building Xen we had to design, iterate, and iterate (then iterate some more). We took what we thought we knew, and put it to the test. We learned how design and scope work together, and how to build momentum as a team. We are extremely proud of what we have accomplished over the year(s)! Despite the long and occasionally frustrating timeline, it has been a real testament to the commitment that this team and this community have for Half-Life." - Adam Engels
Unreal Engine 4 scene
"So I decided I would step out of my comfort zone and create a small environment in an engine I've never used before, UE4. Although I think I did a fairly decent job at the time there were ultimately many nuances I could have done better, but that is the artist dilemma. This project taught me the value of properly blocking out your environment, gathering as many references as you can and to have patience and not rush through assets, when breaking any of these rules I was punished for it. Stay tuned for my next project which will be a giant mech, coming soon Valve time TM." - Vorontsov
Counter-Strike: Global Offensive - Opal
"My goal with this project was to make a fun and compact defuse map, with a simple level flow, ample verticality, and an overlapped layout! I wanted to have interior and exterior, and break the grid a lot, to avoid having that "90 degrees grid" feel in the layout. I needed to have a vista on one side of the map to help with orientation, so I decided to make it a coastal town, inspired by those found on the island of Skopelos, Greece. Expect more updates in the near future, as I'm not yet satisfied with it. Since this is my only CSGO map, I want to put all my time and effort into it, and focus on quality instead of quantity. Thank you everybody for your support and feedback! <3" - MikeGon
Insurgency: Sandstorm - Precinct
by @Xanthi, @Squad, @Jonny Phive, @LATTEH, @Steppenwolf and others at New World Interactive
"Precinct, was a fun and challenging map to work on. We decided early on to melt District and Contact two of our very nostalgic maps together into a single large-scale urban environment. The goal was to preserve the nostalgic feeling and at the same time create something unique and fresh not just a 1:1 copy. In the block-out stage we started playing with different terrain heights, which eventually was the key to accomplish our goal. Terrain height was a bit of a trial and error process; I remember driving up a hill and not having enough torque, oops!!" -Xanthi
Counter-Strike: Global Offensive - Killhouse
"Killhouse showcases brutal duels, player reaction times, and close-quarters combat. A highly vertical layout ensures the sort of unpredictability and replayability ideal for CS:GO’s 2vs.2 "Wingman" game-mode." - FMPONE
Counter-Strike: Global Offensive - Station
by @Roald and @untor
"All experiences contribute to where I am at this point. I am just a hobbiest but I think I learned alot about level design just by doing it and enjoying it. Overal my goal is to improve myself on level design, but also enviorment art. I think I archieved a goal on level design and it's now time to continue on enviorment art. This is where untor morozov comes in. I have met untor a while ago. He made this map 'Waterfall' which was pretty populair. I liked his designs and added him as a friend. When I had this wingman map going on with positive feedback I just contacted him again to work on it with me and since this moment we have had a incredible teamwork. I am gameplay orientated and he is art orientated so we were a great couple. We just enjoyed work on this project and respected eachother and had alot of fun." - Roald
by @Yanzl and Sara Lukanc
"The Gap is a sci-fi thriller first person narrative exploration video game. You play as Joshua Hayes, a neuroscientist trying to figure out what happened, barely remembering anything about his past. It started as a project for our BA thesis and has now grown into a standalone game. It's also my first "real" indie game project, helping me learn a lot about Unreal Engine 4 and game development in general." - Yanzl
Counter-Strike: Global Offensive - Alexandra remake
"My first successful map was born 10 years ago for CS1.6. It was done in just 4 days. Since then it has been ported/improved several times on CS:S then finally on CS:GO. It always had a "dust" theme. Initially i wanted to remake it with an "inferno" style but when the new dust2 came i switched the plan to use the new assets. The map was and is frequently played on public servers especially in Eastern Europe so i had plenty of feedback to improve it. For some it's just another "dust" map, but for me it's my dust2." - Serialmapper
Far Cry 5 - Wetland Turmoil
"I wanted to try working with location design in an (imaginary) open world game for the first time, so I made this backwater cabin neighborhood. At the time I also wanted to see what the limits were in Farcry Arcade and how far I could push it. The level has fixed spawns (a limitation of the editor), but I toyed with the idea of making it work regardless from which direction the player would have approached it. The pathing and player guidance is more or less shaped like the number eight, with the church acting as an outlook. Your task is to eliminate all the bad guys. In the end I wanted to do so much more, but couldn't due to technical limitations. All in all it was a fun experience to make it." - grapen
Counter-Strike: Global Offensive - Trailerpark
by @OrnateBaboon and @Skybex
"We wanted to make a map for CSGO, using a theme that had not been seen in any previous version of Counter-Strike.The map had to incorporate everyday plausibility, provide for enough variety so that things remained visually interesting, but also be flexible enough to allow for the use of low geometry for easy grenade strategies. Being able to immediately recognize a theme in a map is always important, so with all this criteria in mind, A trailer park fitted the bill perfectly. There is still some way to go before a full release, but 2018 was a great year for progress on this project." - OrnateBaboon
Unreal Engine 4 scene
"I was inspired by games like stalker and the last of us. The goal was to make something photoreal with a lot of foliage. It took a couple of iterations but I think I achieved the goal in the end. While making this project I've had to learn a lot about Speedtree to make all the foliage, it was a really cool experience. Right now I'm in the army so unfortunately I can't make any more scenes right now, but after I'll come back I'll try to make more scenes like that." - Corvus
Overwatch - Busan
by @Minos, @[HP], @PhilipK, @IxenonI, Phil Wang, Lucas Annunziata and others at Blizzard Entertainment
"Busan was a challenging map to make. Due to the game having 12 different heroes on screen we have a somewhat limited memory budget for maps, that includes all models, textures, effects, collision data, lighting information, etc... Fitting three radically different areas (Downtown, Sanctuary and MEKA Base) into one single map budget required us to find new ways to optimize our work. In the end, we were even squeezing kilobytes out of collision data to make it all fit, no kidding! But the result speaks for itself, the map was fun to work on and we are very proud of what we accomplished!" - Minos
Counter-Strike: Global Offensive - Highlands
by @ElectroSheep, @El Moroes and @'RZL
"We wanted to make a map in Scotland because, thanks to dishonored 2, we were browsing a lot of references froms this area and we really loved it. I also went myself here in holliday after that. We asked one of our close friends to make some special props, like the police van, the taxi, the phonebox and some others. Unfortunatly the hard development of Dishonored 2 put us in a difficult state where we weren't able to work on the map. So we lost motivation. Then RZL contacted us because he didn't want the project to die so we gave him the keys. And RZL became busy too ^^. Life sometime say NO I guess, hehe. Now Highlands Is my only advanced project I still didn't finished and I'm ready to give it a try, I hope." - ElectroSheep
"Highlands...is this map is a joke? Certainly no but we can say that the development is quite longer than what we expected. Perhaps we learn well how the famous "Valve time" works? :p No seriously I think we can explain that with the motivation. Of course we were motivated to create something cool with this map but with the time and, I think, with what we live in our life we never took the time to do it correctly...I mean we never had a constant rythm on the map. This (and other personal things) led to the current statut of the map; a still "work in progress" map started in 2014. But ElectroSheep came back and his goal is to finish it, and because he's right, I'll come back too to help him. Just, be patient (again) ;)" - El Moroes
Battlefield V - Fjell
by @Puddy, @Pampers and others at DICE
"Fjell was an explosive experiment which paired a new Battlefield dynamic, planes and infantry only, with an epic gosh darn mountain top. Tackling this design combination was like dealing with a bear after you've kicked it in the balls. It was a fun challenge and even though its extreme gameplay is quite polarizing when compared to more middle-of-the-road maps, I am happy that we went there!" - Puddy
Counter-Strike: Global Offensive - Iris
by @BubkeZ and @Oliver
"Iris was born out of a shared interest in the TV-show "Seinfeld", funnily enough. One day BubkeZ noticed I had changed my Steam profile picture to a photo of "George Costanza" and just like that the wheels were in motion! In the beginning, BubkeZ had the vision of an old city environment with lots of dirty alleyways and brick architecture. We didn't want to fall in the trap of making the map look too bleak, so we came up with the idea of making a mid-century town set in autumn. While the map certainly have visual elements from the 50's, I would say the overall theme of Iris is american auto-industry. Making the old cars was definitely my favorite part of making this map!" - Oliver
Unreal Engine 4 scene
"I have always been a fan of retro and vintage, so this was like a dream to me. After watching the first season of True Detective, I immediately fell in love with the office set and the way the series was shot. I have definitely learned a lot from this project, mostly lighting techniques that can fill your scene with a story. The goal was to recreate their environment in my own style, and I'm pretty satisfied with how it turned out. I definitely wasn't expecting this much of positive feedback and I'm really thankful for this community. I want to do something with the environments, not just as a portfolio piece, but make a short film or make a small adventure game out of them." - Brightness
Counter-Strike: Global Offensive - Insertion 2
"Being the follow up to the first Insertion it will have the same overall concept with the spawning and open-world like layout. However this time it will be a more urban setting and overall higher quality art assets. I always love to make environments that feels real. And that are familiar. Its all made up. But the details and various elements in Insertion 2 is from my childhood basically. Friends that grew up in the same place I have recognizes it aswell." - Oskmos
The Door Challenge
Designing Highly Replayable Stealth Levels for Payday 2
Level Design in Max Payne: Roscoe Street Station
Effect and Cause - Titanfall 2 Level Breakdown
2017: Mapcore's Year in Review
Hurg smiles upon you all!
El Moroes reacted to Radu for an article, 2017: Mapcore's Year in Review
(New logo by Yanzl)
I'm sure that by now most of us have our sleeves rolled up and are ready to tackle yet another year, but before we move forward let's take a moment to look back at what 2017 meant for our community. It was a time of immense growth for both professionals and amateurs alike. A time when everyone seemed to have surpassed their former selves. And without slowing down, some have even managed to land their first job in the industry. I don't know what this new year holds, what challenges to overcome will arise, but I know for certain that I'm excited to see everyone become even greater!
2017: Mapcore's Year in Review
Overwatch - Oasis
by Phillip K, Bram Eulaers, Helder Pinto and others
Dishonored 2: Death of the Outsider - Curator level
by electrosheep, kikette and others
Payday 2 - Brooklyn Bank level
by General Vivi
Sniper Elite 4 - Regilino Viaduct
by Beck Shaw and others
Counter-Strike: Global Offensive - Offtime
Team Fortress 2 - Shoreleave
Art pass, props and sound by Freyja
Wolfenstein II: The New Colossus - Farmhouse
Modeled, textured and composed by BJA
Half-Life 2: Downfall
Counter-Strike: Global Offensive - Studio
by ZelZStorm, TanookiSuit3 and Hollandje
Portal 2 - Refraction
Counter Strike: Global Offensive - Breach
by Yanzl and Puddy
Counter-Strike: Global Offensive - Berth
Counter-Strike: Global Offensive - Kaizen
by Andre Valera and Jakuza
Counter-Strike: Global Offensive - Asylum
Half-Life 2: Episode 2 - FusionVille: The Shadow over Ravensmouth
Unreal Engine 4 scene
by Dario Pinto
Counter-Strike: Global Offensive - Grind
by The Horse Strangler, `RZL and MaanMan
Counter-Strike: Global Offensive - Aurelia remake
Counter-Strike: Global Offensive - Tangerine
by Harry Poster
Counter-Strike: Global Offensive - Abbey
by Lizard and TheWhaleMan
Counter-Strike: Global Offensive - Apollo
by Vaya, CrTech, Vorontsov, JSadones
Counter-Strike: Global Offensive - Sirius
by El Exodus
Unreal Engine 4 scene
Counter-Strike: Global Offensive - Subzero
Counter-Strike: Global Offensive - Biome
El Moroes reacted to will2k for an article, Optimizing An Open Map in Source Engine
An open map?
Source engine, which is funnily a Quake engine on steroids (a bit of exaggeration but still), inherited the same limitations of its parents in terms of visibility calculations: BSP and PVS. This fact makes Source, as was Quake engine before, more suitable to rooms and hallways separated by portals where the BSP shines in all its glory.
Inheritably, Source does not like large open maps where the PVS is of considerable size and the over-rendering is a real issue.
If you work with Source engine, then you already know the importance of optimization in a large, detailed map. Optimization becomes even more imperative when the said map is open.
What’s an open map? Good question. The word “open” is an umbrella term to denote any map that does not have traditional hallways and corridors that connect indoors to outdoors. The map is mostly large, outdoors with an unbroken skyline; in other words, the same stuff that source engine nightmares are made of in terms of PVS and BSP.
In a traditional “hallway’d” map with twisted corridors leading to open areas followed by other hallways, and even if you “forgot” to place hints and areaportals, the geometry itself allows the engine to cut visleaves and limit visibility; granted the visleaves’ cuts will be subpar and messy and the PVS will be in excess, but still, the visibility and fps will be relatively under control. A twisted hallway is a remedy to long sight lines after all.
In an open map, and without hallways and enough geometry to help the engine, the PVS risks to be huge and the whole map could be rendered at once from any point (over-rendering). We are talking here about a severe fps killer and a potential slideshow on a medium to low range computer. Source does not like over-rendering; I repeat, Source does not like over-rendering.
I believe a screenshot should be welcome at this stage to illustrate an open map. I’ve chosen a nice medium-size map from CSGO to showcase the issue: de_stmarc.
The shot is taken in Hammer obviously, and you can immediately see that the skybox is one big unbroken body from one edge of the map to the opposite one. This is the classic definition of open map.
Let’s see this map in 2D view from the side.
I have highlighted the skybox in blue so you could see the continuous sky body all over the map. Please note that an open map can have varying skybox shapes but I’ve chosen the simple and classic one to showcase my point where it is easier to see and visualize the concept of open map.
In contrast, a “traditional” map will have several skyboxes, often not connected directly but rather through a system of indoor rooms or hallways, varying in size and shape.
I will have my map de_forlorn as example here.
I have also highlighted the skybox in blue and you can easily notice several skyboxes for CT spawn, T spawn, and Mid/bombsites. These skyboxes are not directly connected to each other but the areas related to them are linked on the lower levels through various indoor locations, some vast (like garage, tunnels…) and some small (like lab hallway…).
If you are not that comfortable with source optimization or feel that certain terms are alien to you, then please read my previous optimization papers and articles before proceeding further in this article (Previous papers can be found here Source Engine Optimization roadmap).
The necessary tools
I’m not revealing a secret when I tell you that the same tools used to optimize any map in Source are exactly the same ones used for optimizing an open map. If you were expecting some magical additional tools, I’m sorry to bust your bubble.
Since the tools are the same (nodraw, func_detail, props, hints, areaportals, occluders…), it is more about how to use them in open maps that makes all the difference.
So, how to properly optimize an open map? Well, you could always pay me to do so for you (joking…not…maybe…I dunno!!)
If the above option is off the table, then read on the rest of this article .
While in a traditional map one might get away without using horizontal hints, it is virtually impossible to skip them (pun intended) in an open map unless you want to witness single digit fps burning your eyes on the screen. They are of utmost importance to negate the "tall visleaves across the map" issue.
In a traditional map, even if you bypass adding horizontal hints, the damage in fps will mostly be local since the skyboxes are not connected and areas are mostly autonomous in terms of PVS. In case of my map “Forlorn” and referring to the 2D diagram above, if I remove horizontal hints from CT spawn, then only this area will suffer from tall visleaves and over-rendering. Obviously, this is not cool in terms of optimization, but at least the effect will be somehow restricted to this area only.
In the case of “Stmarc”, you can certainly see that not including horizontal hints will have tall visleaves seen from across the map as the skybox is one unit. The PVS will grow exponentially and the over-rendering will take its toll on the engine.
Let’s move on to some screenshots and diagrams, shall we.
This is our glorious open map in side view. The blue lines denote the skybox, the dark grey one is the ground, and the green rectangles represent solid regular world brushes such as building bases for example. The red starfish little-man-with-arms-wide-open is the player. The orange hollow rectangles denote the various visleaves that the engine would probably create in the map (most go from ground level to skybox level and this is what I refer to as “tall visleaf”).
If you know your optimization, then you certainly remember that BSP relies on “visibility from a region” approach (for a refresher, please consult my papers Demystifying Source Engine Visleaves and Source Engine PVS - A Closer Look. This simply translates to the following: the player is in visleaf A and visleaf A has direct line of sight to visleaves B, C, D, E, F, and G. The PVS for A in this case would be stored as BCDEFG. Once the engine recognizes that the player is in A, and regardless of the exact position in A, it will proceed to render the whole PVS content. Everything in visleaves BCDEFG will be rendered even though the player is at the extreme end of A and has no line of sight to most of this content.
You can immediately notice the extent of damage you will inflict on your open map if you neglect adding horizontal hints: excess PVS with additional useless content to be rendered at all times.
Now that we established the importance of these horizontal hints in open maps, the question remains: where shall I put these hints?
In the diagram above, the most logical places would be on top of the 3 green rectangles.
We added 3 horizontal hints (H1, H2, H3) on top of the 3 regular brushes in our map (the hint face neatly resting on the top of the regular brush while other faces are textured with “skip”). This will create more visleaves as can be clearly seen in the above diagram, and vvis will take more time to calculate visibility due to the increased number of leaves and portals but this is done for the greater good of humanity your map’s fps.
Now the player is in visleaf A1 and the PVS is reduced to (sit tight in your chair) A2, A3, A4, B1, B2, C3, C4, D1, E4, F3. On top of the nice result of a greatly reduced PVS (and therefore content to render), keep in mind that leaves A4, B2, C4, D1, E4, and F3 are mostly empty since they are way up touching the skybox.
Some folks will start complaining and whining: what the hell dude, I don’t have 3 green rectangles in my map; where would I put my hints?? My answer would be: deal with it!!
Joking aside, open maps will greatly differ in size, shape, geometry, and layout. What you need to do is choose 1 to 5 common height locations in your map where you would implement these hints. Medium maps with mostly uniform building heights can get away with 1 horizontal hint, while complex, large maps with various building heights can do with 4-5 hints.
If your map has a hill made of displacements that separates 2 parts of the map, then it is also a candidate for horizontal hints. You just need to insert a nodraw regular world brush inside the displacement to be used as support for the horizontal hint (the same technique can be used if you have a big non-enterable hollow building made mostly of func_detail/props/displacements).
These might not come into play as much as their horizontal siblings, however they could see a growing potential use depending on the map’s layout, geometry tightness versus openness.
I cannot go through all combinations of open maps obviously to show you how to lay vertical and corner hints; what I will do is choose one diagram representing a typical open map scenario with some scattered houses, streets, and surrounding fields. Once you see how I proceed with these hints, it will become a lot easier for you to implement them in your own map regardless of the differing geometry and layout.
Here’s our typical map viewed from top with grey lines being map borders, green rectangles being houses (solid world brushes), and our tiny red player at the rightmost part of the map. The map has a main street that goes in the middle between houses but the player is not restricted to this path only.
The diagram below shows how I would proceed with my hints for such setup.
This is basically what you get when you give a 5-year-old some crayons.
Seriously though, I just gave each hint a different color so you could discern them on the spot, otherwise it would be hard to tell where each one starts and ends.
Most of these hints go from one side of the map to the other while going from ground level to skybox top; don’t be afraid of having big hints that cross your entire map.
Notice that we have both straight vertical hints (shown from above in the diagram obviously) and corner hints; what I did is that I compartmentalized the map so wherever the player is, chances are they will have the least amount of leaves to render in the PVS (this is just a basic hint system and more fine tuning and additions could be done but you get the gist of it).
To get more details on hint placement, please refer to my paper Hints about Hints - Practical guide on hint brushes placement
If your map has enterable buildings, then it is imperative to separate indoors from outdoors using areaportals; this is top priority.
Make sure to slap an areaportal on each door, doorway, cellar door, window, roof opening, chimney, etc. that leads inside the house in question.
What about outdoor areaportals? Good call. In an open map without much regular world brushes to maneuver, it could get very tricky to set up an outdoor areaportal system to separate areas. However, you should always strive to have one, even if it is one or two areaportals across the map. The reason is very simple: the view frustum culling effect, which, coupled with hints, will yield the best results in cutting visibility around the map.
Continuing with our previous diagram, a simple outdoor areaportal system setup could be as follows (top view).
This setup will make sure that the map is split into 4 areas and whenever you are in one of them as player, the view frustum culling effect will kick in to cull as much detail as possible from the other areas.
Let me show you the setup from a side view to make it easier to visualize.
This is the same areaportal that was closest to the player in the top down view diagram but this time viewed from the side. Unlike hints where it’s fine to have one big hint going across the map, for areaportals, it is best to have several smaller ones that tightly follow the contour of the geometry eventually forming one big areaportal system.
Another possibility for outdoor areaportal system is to have a combination of vertical and horizontal (yes horizontal) areaportals.
If your map is a village for example with a highly detailed central square where most of the action takes place, a potential system could be made of several vertical areaportals that sit in every entrance to the square from adjacent streets, and a horizontal areaportal that “seals” the area and works as a “roof”.
For a practical guide on areaportals placement, please check out my article Practical guide on areaportals placement
Props fade distance
This is a really, really important tool when optimizing large open maps. In case you got distracted while I was making the announcement, I’ll go again: props fading is definitely vital when tackling open maps optimization.
What you need to do is to set an aggressive fade distance for all trivial props that do not contribute to gameplay. Players will look closely at how detailed your map is when they check it out solo on the first run; however, when the action starts and the round is underway, adrenaline, focus, and tunnel vision kick in, and all the details become a blur.
During an intense firefight, players will not notice small props and details up close, let alone at a distance. We need to use this to our advantage to fade props thus releasing engine overhead; a faded prop is not rendered anymore and engine resources will be freed and allocated elsewhere.
Your map geometry will dictate the proper fade distances, but as a rough guideline, small props could have a fade distance anywhere from 800 to 1200 units (flower pot on a window sill, small bucket at the back door, a bottle on the sidewalk…), while medium props could do with 1400-1800 range (a shrub, a power box on the wall, an antenna on the roof, wood plank, gutter pipe, fire hydrant…).
Be very careful though not to prematurely fade critical props used for cover or game tactics (car in the middle of the street, sandbags, stack of crates, dumpster on the sidewalk…).
Many people forget about this technique which is more than needed when it comes to open maps that tend to have larger average PVS than traditional maps.
I showcased in a previous article of mine the fps cost of cheap and expensive assets (Source FPS Cost of Cheap and Expensive Assets).
Get in the habit of using the low-poly model version as well as the cheap texture version in the distant non-playable areas and the high unreachable areas where players won’t have much of close contact with the environment. Potential candidates could include a distant field, the unreachable opposite bank of a river, a garden behind hedges/walls, high rooftops, the 3D sky…).
Fog/Far-z clip plane
This technique, when correctly used, can provide a big boost to your frame rate as parts of the world beyond the opaque fog won’t be rendered at all.
For this technique to work properly, your map should have a foggy/rainy/stormy/dusty/hazy/night setting (use as applicable) where a fully opaque fog won’t appear out of place. Obviously, if your map takes place in a sunny and clear day, this technique won’t work much and it will look inappropriate.
Using this is simple: For example, if your map is set in a rainy and foggy day, you just need to set the fog end distance while having its density set to 1. You will then set the far-z clip plane to something slightly higher than the maximum fog distance (if the fog end distance is 8000 units for example, the far-z could be set to 8200).
This is another good technique to reduce engine overhead and the cost of rendering.
It is true that the 3D sky is used to expand the limits of your level and decorate its surrounding, however, since it is built at 1/16 scale (and expanded in-game), it is also a nice way to decrease rendering costs. Use this to your own advantage and relocate assets in the non-playable areas with limited player interaction to the 3D sky.
One thing to keep in mind though, the 3D sky’s visleaf is rendered at all times on top of the PVS in the playable area. Do not go overboard and make an extra complex, highly expensive 3D sky or you would be defeating the purpose of this optimization technique.
You thought I forgot about occluders? Not a chance as these are the big guns when it comes to large open maps with little world brushes to use for other optimization techniques.
Let’s clear one thing first; if your map is made mostly of brushwork and displacements with little to no props, then there is absolutely no need to resort to occluders as they’d be totally useless in this case. Only when the map is loaded with models and props in an open setup with little regular world brushes that occluders come to play in force.
To place occluders, you would search for areas where these occluders could make the most impact (low fps, high traffic, props abundance) since they run in real time and are expensive, otherwise their cost would outweigh their benefit in terms of frame rate variation.
Remember that occluders rely on the player’s position and field of view relative to the occluder to calculate what gets culled. You need to place them in a way to maximize the number of props to be culled behind them when the player stands in front of these occluders.
Let’s see some examples.
We go back to our famous top down diagram; the occluder is dark blue placed on the left wall of the large house while the little black stars represent various props and models. The 2 diagonal black lines denote the player’s FOV relative to the occluder. Anything behind the occluder and within the view frustum will be culled.
That’s nice; we are able to cull 4 props but is it enough? It is not optimal as we can still do better. What if we move the occluder to the right wall of the house?
Much better if you ask me. 5 additional props were added to the culling process meaning less overhead and fewer resources to render for the engine. That is why I said earlier it is all about maximizing the impact of the occluder by placing it in a way relative to the player’s position that maximizes the number of culled models.
Here’s another example (still top down view).
The player has moved to the middle of the central street, and beyond that L-shaped house is an open field with a lot of props scattered around. One way to implement occluders is as showcased in the above diagram. Notice how I arranged 2 perpendicular occluders along the walls for the maximum occlusion effect as all of these props in the field are not rendered from that player location.
Another way to arrange occluders in this case would be diagonally across the L-shaped house (split into 2 or 3 occluders if needed to accommodate the nearby geometry; they can be floating without the need to seal an area).
If you’re feeling brave enough (you should be after reaching this far in this article), you could also add an extra occluder along the wall of the house to the left of the L-shaped house to further enhance the view frustum occlusion effect and cover more props in the field.
The most common places to add occluders in open maps include a displacement hill that separates parts of the map, a hedge that stands between a street and a field full of props, a floating wall between a house garden and the street, the walls of a large house, the walls of a tall building, a ceiling when it separates multiple levels…
To read more about occluders placement and cost, please consult my article Practical guide on occluders placement
The foundation of optimization in Source engine will be the same whether it is a traditional map or an open one. You will heavily rely on func_detail, nodraw, displacement, props… to achieve your goals but it is the way you use these tools in an open map that makes all the difference.
One might get away with being a bit sloppy with optimization in a traditional map, however, make no mistake that an open map won’t be any forgiving if you decide to skip a beat in your optimization system.
Talking about different open maps and formulating varying optimization systems for them could fill articles; I hope this article has shed enough light on the open maps optimization approach to let you easily design a system for your own map.
El Moroes reacted to Mapcore for an article, Day of Infamy Mapping Contest
Participants have from the 15th of September 2016 until Midnight (GMT) on the 22nd of December 2016 to create, test and upload an original or Day of Defeat inspired map for Day of Infamy (www.dayofinfamy.com)
Map included officially in game
Void Surround Sound Headphones
M330 Mouse Pad
All Wall Worm Source Modelling Tools
M330 Mouse Pad
All Wall Worm Source Modelling Tools
M330 Mouse Pad
All Wall Worm Source Modelling Tools
M330 Mouse Pad
All Wall Worm Source Modelling Tools
(*All prizes are subject to participant eligibility. No cash value. The contest Organizers and Sponsors reserve the right to change or remove the prize structure at any point with or without reason.)
In addition to the prizes stated above, GameBanana will also be offering a sub-prize for the best development blog, work in progress or tutorial created throughout the process.
This is an entirely optional part of the contest and is open to members of all communities.
To enter simply create either a development blog / work in progress page OR a level design tutorial / guide for Day of Infamy on either GameBanana, MapCore or the Insurgency Forums.
Entries must be uploaded on or before Midnight (GMT) on the 22nd of December 2016, and include “[DoI Contest]” in the title. Entries will be judged by members of the GameBanana team, as they appeared at the deadline.. No changes or updates are permitted during the judging phase.
Rules and Frequently asks Questions
The submission must be a playable map for the PC version of Day of Infamy.
Remakes of existing maps are not allowed, however maps inspired by classic DoD maps are encouraged.
Entries must be submitted to the Day of Infamy mapping contest section of BOTH GameBanana.com and the Steam Workshop before the deadline.
Multiple entries are permitted, however submissions will be judged on individual quality rather than quantity.
Team based entries are permitted, however the entrants will have to agree how to split any prizes awarded, prior to prize claim and dispatch.
It is essential to thoroughly test your submission before the deadline as entries cannot be modified during the judging phase.
Exceptions: Changes to the submission profile are permitted after the deadline, provided they are purely aesthetic and that the map file does not change. (E.g. Editing the description / screenshots)
Maps that were under creation prior to the announcement of this contest can be entered, provided a completed version has not been released for public Download.
All custom textures, models or code must be contained within the download file or embedded into the .bsp.
Authors are free to share their content on any other websites or services they wish, however the file must remain free to download and play, without requiring membership or payment.
If the submission is distributed on an external website or service, it must clearly state that the submission was created for the "GameBanana / MapCore Day of Infamy Mapping Contest 2016”.
Authors must be able to accept cash payments via paypal and will be required to fill in a prize claim form prior to payment. Winners of hardware and physical products will also be required to provide a valid shipping address.
Judges and individuals associated with organising this contest cannot enter or assist entrants.
Entries must clearly state which game mode the level is designed for.
Participant eligibility: The “GameBanana / MapCore Day of Infamy Mapping Contest 2016” is open to any individual, or teams of individuals, provided they comply with the following:
Participants may not be an employee of the “Organiser” or “Sponsors”.
Participants may not have taken part in the preparation or announcement of this
Participants may not be a direct relative, spouse, direct employee, or long term
partner of any of the above definitions (a - c).
Legal Age: This contest is open to any individual who meet the above “participant eligibility” criteria. In the event of participant who has not reached the legal age in his/her state winning one or more prizes defined below, he/she must provide contact details for the legal guardian who will claim the prize(s).
TWO (2) copies of the map are required for this contest, and must be uploaded on or before the deadline. The primary version (used for judging) must be submitted to GameBanana.com and placed in the “Day of Infamy > Mapping Contest 2016” category.
The second version must be uploaded to the Day of Infamy Steam Workshop
No changes to the downloadable file can be made during the judging phase. Please remember to ensure that all relevant custom content is included, and that your map is thoroughly tested.
Maps will be judged by the developers at New World along with the staff at MapCore and GameBanana. Each map will be scored on the following categories, and given a total score out of 100.
Gameplay (40 marks)
Visuals (30 marks)
Originality (15 marks)
Performance / Optimization (15 marks)
El Moroes reacted to FMPONE for an article, 2015: Mapcore's Year in Review
(Art by Thurnip)
This overview proves how talented our community is. We share, give feedback and learn from one another. Lots of our members have made it into the game industry and continue to make their mark working for high-profile studios. Our articles were shared around the world and our collaborative CS:GO contest was a huge success. We can only conclude that 2015 was again a stellar year for the Core and we are looking forward to an even better 2016!
2015: Mapcore's Year in Review
It was a banner year. Here’s a taste of what our community created:
Temple of Utu by Minos
Corridor by JonnyPhive
Rails by Deh0lise
Cold Fusion by Rusk
Half-Life 2 Scene by Psy
Resort by 'RZL and Yanzl
Zoo by Squad and Yanzl
Santorini by FMPONE and Dimsane
Corridor by RaVaGe
Seat by penE
Half-Life 2 UE4 Corridor by PogoP
Tulip by catfood
Volcano by 2d-chris
Chilly UE4 Scene by TheOnlyDoubleF
High-quality original content:
Grand Prize Winner Announced
Hurg Smiles Upon You All!
El Moroes reacted to will2k for an article, Viability of Hostage Rescue Scenario in CS:GO
This level design article is about the past and the present of the hostage rescue mode in Counter-Strike. Showcasing the inherent issues that accompanied the scenario allowing the bomb/defuse mode to gain traction and popularity. This article will also present what can be done, level design wise, to remedy some of the shortfalls and allow the scenario to be viable.
A historical background
Counter-Strike officially started life in June 1999 with the release of beta 1, and it shipped with four maps, that’s right, four whole maps. They were all hostage rescue maps and the prefix used for these maps was cs_ as opposed to the standard deathmatch maps starting with dm_. This prefix was an abbreviation of the game’s name (Counter-Strike) which hints to this hostage-rescue scenario being the only one in the minds of Gooseman and Cliffe, the creators of CS, at the time of launch.
Fast forward a couple of months, beta 4 rolled out in November 1999 bringing to the table a new scenario, bomb defuse. The new maps carried the prefix de_ and while one would think that the hostage rescue maps would be switched to hr_ prefix, they kept the same prefix which started to be referred to as the “Classic Scenario”. Counter-Strike was built on hostage rescue scenario.
I started playing CS in beta 2 in August 1999 (I totally missed beta 1, screw me) and maps like Assault and Siege were all the rage at LAN parties. The nearest LAN/internet café was a 5-minute drive from my place, and LAN parties with friends used to be a blast full of shouting, cursing, bluffing, noob-trashing; the standard menu for a CS session. Good times.
Siege, the oldest CS map (beta 1), and Assault (beta 1.1) were the epitome of the game. You had to dive in as a CT deep into the T stronghold to rescue the hostages and bring them back to safety. These maps were the most played on LANs and embodied the style of early CS gameplay. At the LAN place where I used to wage my virtual battles, Assault equaled CS, literally. A fun fact is that when Dust came out, I started a LAN session with this map and everyone in the room shouted at me: "What the hell is this? We wanna play CS!" For my friends, Assault was CS.
However, those rosy days for hostage rescue began to turn into grim grey when folks started playing bomb defuse scenario and realized how…fun it was. A map like Dust almost single-handedly pushed the scenario into higher ground with its bright environment/textures, clear/wide paths and its ease of use and noob-friendliness. A year later, around Summer 2000, Counter-Strike was now equivalent to Dust for my friends.
How did this happen? What went wrong?
Inherent flaws of hostage rescue
Hostage rescue is a very delicate and tough scenario for law enforcement operators in the real world. It puts the assailing team at a great disadvantage against heavily-armed barricaded hostage-takers who are probably using civilian hostages as human shields and as a bargaining chip for a later escape.
As you can deduce, transferring this scenario as realistically as possible into the game will not fare well, and this disadvantage will carry on for the CT team. The problem is only exacerbated when you add the more or less “flawed” game mechanics to the scenario. This is exactly what went wrong with hostage rescue scenario in case you are still wondering about the rhetoric questions at the end of the historical background introduction. The popularity of cs_ scenario started dwindling and the rise of the bomb/defuse scenario only made things worse.
Almost all the early cs_ maps featured a relatively tiny hostage zone/room having one entryway usually sealed with closed doors that the CT must open to get access inside. This room was typically located behind T spawn which made the area a camping ground and made camping that zone an obvious and rewarding tactic for Ts. The doors having to be manually opened with a loudening sound made things worse and negated any surprise or sneaky rush towards the hostages. A classic example is the hostage area and T spawn in cs_assault.
I dare not think of how many Ts are camping behind those doors
Another equally important camp fest occurred in the hostage rescue zone. Early designs made the rescue zone relatively small with one or two access paths that can be defended from one location. If the CT team manages to reach the hostages and rescue them, the Ts could easily fall back to the rescue zone to camp and patiently wait for the CTs to show up. The hostage rescue zone in cs_italy is a nice example to showcase how one T could camp in the southernmost spot in the zone allowing him to monitor both entryways, from market and from wine cellar, within the same field of view. CT slaughter was almost a guaranteed thing to happen.
A CT will show up any second now; imminent slaughter commencing in ...3, 2, 1
A third flaw was the hostages themselves. They were difficult to escort and protect and were easily stuck or left behind in various parts of the maps between their initial hostage zone and the final rescue zone. I lost count of how many times I rescued the hostages and ran as fast as I could to the rescue zone, reaching it with a big grin on my face only to turn around and find out that only one or two of the four hostages actually followed me; the others were randomly stuck on a ladder, door frame, window ledge, vent, chair, table…I could go on but my blood is starting to boil just thinking of this.
To add insult to injury, hostages could also be killed or “stolen” for ultimate trolling. When Ts were stacked on money, they could easily kill all the hostages, basically turning the round to a frustrating terrorist hunt for CTs. In early CS versions, a CT teammate could press the “use” key on a hostage that you were already escorting to steal it. This would leave you helplessly wondering where the hell did the 4th hostage go in case you did not catch the teammate performing the action.
Lastly, maps themselves contributed to the issues that were piling up against hostage rescue scenario. If you are a CS veteran and you were around the early betas in 1999, you would most certainly remember how quickly hostage rescue maps were pruned from one beta to another; some maps even had a life span of 1 week before being discarded out of the official roster. Most of these early cs maps featured dark, nightly environments that were unfriendly to both newcomers and established players. Other maps had a confusing-as-hell labyrinthine layout that confused even the most great-sense-of-direction players, and made remembering paths nigh impossible. Some of these maps had narrow twisted paths and choke points, vents, and ladders that not only frustrated players (especially CTs) but also made rescuing and escorting the hostages more of wishful thinking. The icing on the cake was the different gimmicks introduced in some maps that made a frustrating gameplay/layout even more annoying: some maps had a machine gun nest in T spawn allowing Ts to master and perfect the art of CT slaughtering while other maps had flammable drums that could be shot and blasted for the ultimate carnage right next to the hostage zone. Good example maps include cs_prison, cs_bunker, cs_iraq, cs_hideout, cs_facility, cs_desert, among many others.
Meanwhile, bomb/defuse scenario was gaining grounds at an increased rate and before too long, hostage rescue was relegated to a distant second place in terms of popularity among players and level designers alike.
As a small experiment, I tallied the number of custom hostage and defuse maps submitted on Gamebanana for Counter-Strike Source and Global Offensive. For CS:GO, there are 761 de_ maps against 157 hostage maps while for CS:S, the figures are 4060 de_ for 1244 cs_ maps. The disparity is rather meaningful as the ratio in CS:GO is 4.85:1 while for CS:S the number is 3.26:1. This means that for each hostage map in CS:GO there are almost five maps of bomb/defuse whereas this number drops slightly to almost three maps for CS:S. With CS:GO putting extra focus on competitive gameplay, this ratio is bound to further grow widening the rift between bomb/defuse and hostage rescue maps.
That’s it? Is it done for cs_ maps? Shall we prepare the obituary or is there a magical solution to breathe some fire and life in them?
Solutions for viability
There is a magical solution that involves you transferring a large sum of cash to my bank account, then my “guys” will contact your “guys” to deliver the “solution”. The drop point will be at the…apparently, there has been a mix-up, this is for another “deal” …nervous chuckle.
Seriously though, while there is no magical solution that will lift hostage rescue onto the rainbow, there are a couple of things that level designers can do to start injecting some momentum to the scenario. Luckily for us, Valve has already paved the way (so these “Volvo pls fix pls” do work after all?). In March 2013, Valve introduced a major CS:GO update that completely overhauled the hostage rescue scenario mechanics and introduced cs_militia as well. The update was a game changer and a much needed tweak towards a better hostage rescue gamemode.
We now have two hostages instead of four, and the CTs only need to rescue one of them to win the round. Moreover, the hostage does not stupidly follow the CT but instead is carried on the CT’s shoulders. Obviously the movement speed of the CT carrying the hostage is decreased but this “inconvenience” is countered with added bonus round time and the fact that the CT doesn’t have to glance over his shoulders every five seconds to make sure the hostages are still following him (this kind of distraction can prove fatal to the CT escorting the hostages). The hostages’ spawn location is randomized and can be controlled by the level designer. A nice change is that hostages don’t die anymore thus cutting any chance of Ts trolling (you still lose money when you shoot a hostage – shooting a hostage is pretty pointless now akin to shooting yourself in the foot).
This is all good news if you ask me; hostage rescue is on the right path to become popular and viable again. With Valve doing the first half of the change, level designers have the duty to continue with the second half.
As a first suggested solution, let us start treating hostage rescue as bomb defuse. Let’s be honest, bomb defuse works really well, so why not transfer this “experience” into hostage rescue. What we can do is to have a hostage rescue map’s layout mimic one of bomb defuse – that is have two hostage zones that are similarly placed as two bomb sites. We need to start treating a hostage zone like a bomb site with all accompanying techniques of rushing, pushing, faking, peeking, holding, smoking, flashing, etc. The good thing about this is that whatever knowledge, skill, and layout awareness that players have acquired from defuse scenarios will transfer effortlessly to the hostage rescue scenario; you do not need to learn new tactics and strategies. The roles will be inversed: instead of Ts rushing bomb sites and CTs defending, CTs will push hostage zones and Ts will defend and rotate.
Sounds logical, right? Some people might argue that having 2 separate hostage zones is not “realistic” and my answer is Counter-Strike was never about realism (carrying and running around with a 7 kg (15.5 lb), 1.2 m (47.2 inch) AWP sniper rifle with 25x telescopic sight, quickscoping and headshotting opponents is the epitome of “realism”). If you want a realistic hostage rescue scenario, then you are better off playing the original Rainbow Six Rogue Spear and SWAT 3 from 1999, or the more recent ARMA and Insurgency for a realistic military setting. I practice what I preach and I already implemented this technique in my last map “cs_calm”. The map was a remake of my CS 1.5 map from 2003 and obviously I made the “mistake” at that time to follow the trend set by official maps of having one hostage zone right behind T spawn. A playtest on Reddit CS:GO servers back in March 2015 confirmed that this setup won’t work well as Ts will inevitably abuse the hostage zone.
I made some radical layout changes towards T spawn and hostage zone and created two new hostage zones on the upper and lower levels of the map that are connected by a back hallway to allow quick rotations (in addition to the one through T spawn). Obviously, there is no direct line of sight between hostage zones to prevent 1-zone camping. Ts have absolutely no incentive to camp one zone as CTs can reach the other one, rescue the hostage and head back to the rescue zone without being spotted from the other zone. CTs actually have a chance of winning the round by rescuing the hostages.
I like to believe the new layout worked well. Only time and more hostage rescue maps will tell.
Layout of the map "cs_calm"
Rescue zone anti-camping
We have remedied the hostage zone camping but we still need to tend to the rescue zone camping issue. A solution to this is to have two rescue zones in a similar setup to what is nicely done in cs_office. While Ts can still camp one zone, they risk a big chance of having CTs reach the other rescue zone. Again, CTs will have a viable option to save the hostages without being shredded by camping Ts. If the layout does not allow or facilitate having two rescue zones, then one big rescue zone with multiple entrances (three is a good number) should work fine. The trick here is to have the entrances not easily covered within the same field of view to prevent camping.
Into the zone
Just as we established that we should treat hostage zones like bomb sites, it goes without saying that each hostage zone should have at least 2 to 3 entry points. It’s pretty pointless to have only one entrance as this totally defeats the purpose of spreading hostages into two zones. The different entryways should also not be covered within the same field of view of one T; if a T decides to camp the zone, then he should be able to cover two entrances from one point leaving the third one more or less at a dead angle and viable for a CT rush or stealth/sneak surprise.
Showcase of Hostage Zone A on the map "cs_calm"
The above screenshot showcases “Hostage Zone A” in cs_calm. A terrorist will typically camp near the hostage covering the two encircled entrances. The third entrance from upper level denoted by the arrow is not in the direct FOV, and is prone to a surprise attack by CTs that could catch the camping T off guard. If possible, try to spread the entrances on different vertical levels to spice things up and keep Ts on their toes.
Lastly, it is a good idea to have a connector between hostage zones to allow fast rotations but without having a direct line of sight between hostage zones. We want to make the scenario fairer to CTs but not at the expense of Ts, inadvertently making it unfair for them.
Hostage rescue is a fun scenario if you ask me. It had many inherited and added flaws that contributed to its waning but it’s nothing that can’t be reversed. We, as level designers, need to push some changes to put the scenario back on track. What I just showcased in this article might not be the only viable solutions but they certainly are a step in the right direction. Level designers are intimidated by players who shun away from cs_ maps, and this turns into a vicious circle where players avoid hostage rescue maps and mappers in return avoid designing them. We need to break this cycle and designers need to bravely embrace the solutions I presented here or come up with their own solutions. The more cs_ maps that come out and get tested, the more we could validate these solutions as viable.
In either case, we need to get proactive towards hostage rescue scenario; after all, this is the cornerstone that Counter-Strike was built upon.
El Moroes 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
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.
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:
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:
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.
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
El Moroes reacted to leplubodeslapin for an article, Source Lighting Technical Analysis: Part One
After the announcement of the Reddit + Mapcore mapping contest, the website has welcomed many newcomers. A proof that, even if it is a twelve year old game engine, Source engine attracts map makers, and there are lots of reasons for that. It is common knowledge that technology has moved forward since 2003, and many new game engines have found various techniques and methods to improve their renderings, making the Source Engine older and older. Nevertheless, it still has its very specific visual aspect that makes it appealing. The lighting system in Source is most definitely one of the key aspects to that, and at the end of this article you will know why.
About the reality...
Light in the real world is still a subject with a lot of pending questions, we do not know exactly what it is, but we have a good idea of how it behaves. The most common physic model of light element is the photon, symbolized as a single-point particle moving in space. The more photons there are, the more powerful light is. But light is in the same time a wave, depending on the wavelengths light can have all kind of color properties (monochrome or combined colors). Light travels through space without especially needing matter to travel (the space is the best example; even without matter the sun can still light the earth). And when it encounters matter, different kind of things can happen:
Light can bounce and continue its travel to another direction Light can be absorbed by the matter (and the energy can be transformed to heat) Light can go through the matter, for example with air or water, some properties might change but it goes through it And all these things can be combined or happen individually. If you can see any object outside, it is only because a massive amount of photons traveled into space, through the earth’s atmosphere, bounced on all the surfaces of the object you are looking at, and finally came into your eyes.
How can such a complex physical behavior from nature be simulated and integrated into virtual 3D renderings?
One of the oldest method is still used today because of its accuracy: the ray-tracing method. Just to be clear, it is NOT used in game engines because it is incredibly expensive, but I believe it is important to know how and why it has been made the way it is, since it probably influenced the way lighting is handled in Source and most videogame engines. Instead of simulating enormous amount of photons traveling from the lights to the eye/camera, it does the exact opposite. If you want a picture with a 1000x1000 resolution, you will only need to simulate the travel of 1 000 000 photons (or “rays”), 1 for each pixel. Each ray is calculated individually until it reaches the light origins, and at the end the result is 1 pixel color integrated in the full picture.
By using the laws of physics we discovered centuries ago, we can obtain a physically-accurate rendering that looks incredibly realistic. This method is used almost everywhere, from architectural renderings to movies. As an example, you can watch The Third & The Seventh by Alex Roman, one of the most famous CGI videos of all time. And because it is an efficient way to render 3D virtual elements with great lighting, it will influence other methods, such as the lightmap baking method.
OKAY LET’S FINALLY TALK ABOUT THE SOURCE ENGINE, ALRIGHT!
A “lightmap” is a grid that is added on every single brush face you have on your map. The squares defined by the grid are called Luxels (they are kind of “lighting pixels”). Each luxel get its 2 own properties: a color and a brightness. You can see the lightmap grids in hammer by switching your 3D preview to 3D lightmap grid mode.
You can also see them in-game with the console command mat_luxels 1 (without and with).
During the compilation process, a program named VRAD.exe is used. Its role is to find the color and brightness to apply for every single luxel in your map. Light starts from the light entities and from the sky (from the tools/toolsskybox texture actually, using the parameter values that has been filled in the light_environment entity), travels through space and when it meets a brush face:
It is partially absorbed in the lightmap grid A less bright ray bounces from the face Here is an animated picture to show how a lightmap grid can be filled with a single light entity:
When you compile your map, at first the lightmaps are all full black, but progressively VRAD will compute the lightmaps with all the light entities (one by one) and combine them all at the end. Finally, the lightmaps obtained are applied to the corresponding brush faces, as an additive layer to the texture used on that face. Let us take a look at a wall texture for example.
On the left, you have the texture as you can see it in hammer. When you compile your map, it generates the lightmaps and at the end you obtain the result on the right in-game. Unfortunately, luxels are much rougher, with a lower resolution, more like this.
On the left you have a lightmap grid with the default luxel size of 16 units generated my VRAD, a blur filter is applied and you obtain something close to the result on the right in the game.
In case you did not know, you can change the lightmap grid scale with the “Lightmap Scale” value with the texture tool. It is better to use values that are squares of 2, such as 16, 8, 4 or even 2. Do not go below 2, it might cause issues (with decals for example). Only use lower values than the default 16 if you think it's really useful, because you will drastically increase your map file size and compilation time with precise lightmap grids. Of course, you can also use greater values in order to optimize your map, with values such as 32, 64 or even 128 on very flat areas or surfaces that are far away from the playable areas. You can get more infos about lightmaps on Valve’s Wiki page.
But as we said before, light also bounces from the surface until it meets another brush, using radiosity algorithms. Because of that, even if a room does not have any light entity in it, rays can bounce on the floor and light the walls/ceiling, therefore it is not full black.
Here’s an example:
The maximum amount of bounces can be fixed with the VRAD command -bounce X (with X being the maximum amount of bounces allowed). The 100 default value should be more than enough.
Another thing taken into account by VRAD is the normal direction of each luxel: if the light comes directly against the luxel or brushes against it, it will not behave in the same way. This is what we call the angle of incidence of light.
Let us take the example of a light_spot lighting a cylinder, the light will bright gradually the surface - from fully bright at the bottom to slightly visible at the top.
In-hammer view on the left, in-game view on the right
Light Falloff laws
One of the things that made the Source Engine lighting much more realistic than any others in 2004 is the light falloff system. Alright, we saw that light can travel through space until it meets something, but how does it travel through space? At the same brightness, whatever the distance is between the light origin and destination? Maybe sometimes yes… but most of the time no.
Imagine a simple situation of a room with 1 single point light inside. The light is turned on, it produces photons that are going in all the directions around it. As you might imagine, photons are all going in their own direction and have absolutely no reason to deviate from their trajectory.
At one time, let’s picture billions of photons going in all the directions possible around the light, the moment after, they are all a bit further in their own trajectory, and all the photons are still there, in this “wave”. But, as each photon follows its own trajectory, they will all spread apart, making the photon density lower and lower.
As we said before, the more photons there are, the more powerful light is. And the highest the density, the more intense light is. Intensity of light can be expressed like this:
You have to keep in mind that all of this happens in 3D, therefore the “waves” of photons aren’t circles but spheres. And the area of a sphere is its surface, expressed like this:
(R is the radius of the sphere)
If we integrate that surface area in the previous equation:
With ♥ being a constant number. We can see the Intensity is therefore proportional to the reverse of the square of the distance between the photons and their light origin.
So, the further light travels, the lower is its intensity. And the falloff is proportional to the inverse of the square of the distance.
Consequently, the corners of our room will get darker, because they are farther away from the light (plus they don’t directly face the light, the angle of incidence is lower than the walls/floor/ceiling).
This is what we call the Inverse-Square law, it’s a very well-known behavior of the light in the field of photography and cinema. People have to deal with it to make sure to get the best exposure they can get.
This law is true when light spreads in all possible directions, but you can also focus light in one direction and reduce the spread, with lenses for example. This is why, when Valve decided to integrate a lighting falloff law in their engine, they decided to use a method not only following the inverse-square law but also giving to mapmakers the opportunity to alter the law for each light entity.
Constant, Linear, Quadratic... Wait, what?
In math, there is a very frequent type of functions, named polynomial functions. The concept is simple, it’s a sum of several terms, like this:
Every time, there is a constant factor (the “a” thing, a0 being the first one, a1 the second one, a2 the third one...), multiplied with the variable x at a certain degree:
x^0 = 1 : degree 0 x^1 = x : degree 1 x^2 : degree 2 x^3 : degree 3 ... And
a0 is the constant named “constant coefficient” (associated to degree 0) a1 is the constant named “linear coefficient” (associated to degree 1) a2 is the constant named “quadratic coefficient” (associated to degree 2) Usually, the function has an end, and we call it by the highest degree of x it uses. For example, a “polynomial of the second degree” is written:
Then, if we take the expression from the inverse-square law, which was:
With a2 = 1 and D being the variable of distance from the light origin.
In Source, the constant ♥ is actually the brightness (the value you configure here).
It is simply an inverse polynomial of the second degree, with a0 and a1 equal to zero. And we could write it like this:
And here you have it! This is approximately the equation used by VRAD to determine the intensity of light for each luxel during the compilation. And you can alter it by changing the values of the 3 variables constant, linear and quadratic, for any of your light / light_spot entity in your level.
Actually you set proportions of each variable against the other two, and only a percentage for each variable is saved. For example:
By default, constant and linear are set to 0 and quadratic to 1, which means a 100%quadratic lighting attenuation. Therefore, by default lights in Source Engine follows the classic Inverse-Square law.
If you look at the page dedicated to the constant-linear-quadratic falloff system on Valve’s Wiki, it’s explained that the intensity of light is boosted by 100 for the linear part of equation and 10 000 for the quadratic part of equation. This is due to the fact that inverse formulas in equations always drop drastically at the beginning, and therefore a light with a brightness of 200 would only be efficient in a distance of 5 units and therefore completely pointless.
You would have to boost your brightness a lot in hammer to make the light visible, that's what Valve decided to make automatically.
The following equation is a personal guess of what could be the one used by VRAD:
With constant, linear and quadratic being percentage values. The blue part is here to determine the brightness to apply, allowing to boost the value set in hammer if it is as least partially using linear or quadratic falloff. The orange part is the falloff part of equation, making the brightness attenuation depending of the distance the point studied is from the light origin.
The best way to see how this equation works is to visualize it in a 2D graph:
This website provides a great way to see 2D graphics associated to functions. On the left, you can find all the elements needed with at first the inputs (in a folder named “INPUTS”), which are:
a0 is the Constant coefficient that you enter in hammer a1 is the Linear coefficient a2 is the Quadratic coefficient B is the Brightness coefficient In another folder are the 3 coefficients constant, linear and quadratic, automatically transformed into a percentage form. And finally, the function I(D) is the Intensity function depending on the distance D. The drawing of the function is visible in the rest of the webpage.
Try to interact with it!
This concludes the first part, the second part will come in about two weeks. We will see some examples of application of this Constant-Linear-Quadratic Falloff system, and a simpler alternative. We will also see how lighting works on models and dynamic lighting systems integrated in source games.Thank you for reading!
Part Two : link
El Moroes reacted to FMPONE for an article, Making a Map: CS_Museum
The creation of a map begins with an idea.
In the case of my most recent project, CS_MUSEUM, I needed a basic look which would resonate with players immediately. The thought of making a Museum worked… it was a simple one, it had been done before (although this wouldn't be a re-make of the classic DE_MUSEUM by Theropod-X). Players would understand a Museum environment, and it fit in the Counter-Strike world.
Forming a map’s final look is complicated, though, and requires thought about what kind of architecture, colors, and lighting you – an artist or level designer – will pursue.
I’d been playing a lot of the classic map CS_OFFICE, which requires players to storm into close quarters for indoor combat. That kind of game-play is fast and unforgiving, I dig the kind of matches it creates. CS_ASSAULT, I shouldn't forget to mention, is another great map that defines the "siege a building and rescue the hostages" genre. Actually, most of my favorite CS_ maps including Militia also foster similarly dynamic games that challenge you to be sneaky but also use brute force to accomplish your objectives.
So, I set out to make a hostage rescue map like Office and its kin. Studying prior maps is a good way to establish what works well, and avoid what doesn't.
One other map that influenced my thinking: CS_CABARET by Alex Roycewicz.
Cabaret is a great map — it got Alex a job at Infinity Ward long prior to that illustrious studio being kicked in the nuts super hard by mega-publisher-that-will-remain-unnamed.
It was from Cabaret that I basically ripped off the front of Museum... with a few changes.
In truth, though, I had some bones to pick with Cabaret.
Unforgivably, there was no sense of vertical space on the outside of the strip club. Also, while the building exterior is convincingly rendered, the overall space is too geometric: everything seems to face the viewer on an imaginary grid, which is no coincidence, that’s how the Hammer editor encourages people to make maps.
Cabaret on the grid:
Museum screws the grid:
If this analysis is starting to sound harsh, it’s worth noting that Cabaret was one of the best custom maps of its time, so this is more of a modern critique of older game art.
As is often the case with older game art, most of the limitations or flaws obvious to modern eyes were not the creator’s fault: Hammer around the era of Counter-Strike: Source (for which Cabaret was made) did not have all the technology I made use of for Museum. One example is “instances” (the pale green elements in the overview above) which are brushwork more akin to models than typical brushwork, because they can be rotated “off the grid” and not cause compilation problems normally associated with brushwork which is off the grid. Thanks to instances, I was able to rotate buildings to achieve a more natural, organic look — such as this bridge:
In order to actually create the specific buildings in the map, concept art and photographic references were key.
Here's an explanation of the Museum front.
The most pertinent point to make here is the difficulty of knowing when a photographic reference is valuable, and what makes it valuable. To explain this in extreme detail might be delving into an area of “talent”... or it might be worth the subsequent explanation I’ll now provide. In any case, this should explain my process.
The best photographic references share one crucial element: readability. Complex buildings such as the one above, if they are to be useful for our purposes, must be able to be broken down into clean, clear shapes. I was confident using the logic explored in the line-work above (I did this part in my head), that the building could be broken down and translated successfully.
The building begins to take shape, with the red lines becoming props. When using Hammer, what becomes a prop and what remains brushwork largely comes down to the default assets you have to work with.
Talented 3D modelers have their choice of creating new content, but their time is precious and each art asset is an investment, so even then it’s best to think about default materials and their role in your work.
This lovely picture inspired the placement of the obelisks, and secondarily the pond on the right of the Museum.
Using concept art and photos in conjunction with my imagination, I had derived a basic visual identity for the map:
Obvious reference: the Brooklyn bridge; non-obvious reference, this lovely piece from Deviant Art:
Making a map is about looking at the world around you and seeing something inspiring enough to create a desire within you to render it and mold it for your own purposes.
By this point in time you may be shouting IT’S A MAP – TALK ABOUT THE GAME-PLAY, TALK ABOUT THE GREY-BOXING YOU FOOL! …and, while the playability of Museum ended up better than I could have imagined, there is no glory in my process for that particular aspect of the map. Uh oh, he’s gonna say he didn’t grey-box it, isn’t he…
First, the excuses: previously, I'd recreated the Natural Selection 1 map NS_VEIL for NS2, based solely upon my own literal eyeballing of the geometry, without any scale-guide, in a different editor and a different unit system. To put all that gibberish into other words, I’d done nothing for two months other than study the rigid grey-boxery of another mapper, then spent another 10 months making that geometry fit into the context of a new game and engine. I’d worked with fastidiously organized layers, done everything by the book, guv, I swear.
While important for a commercial product, that experience had temporarily tired me somewhat of the (smarter) formalistic approach. As a result, no substantial grey-boxing would take place for Museum. Manic energy took the place of “rules” and “common sense”:
Basically, I was creating stuff I thought looked cool, not getting terribly fussed about what direction it would all head. This is the way newbie mappers work, or idiots, or both… but it can be done if you’re smart about it.
Certain things can’t be bullshitted around, though: your map must be in proper proportion to the players, and it must maintain sensible sight-lines considering the game type. You need to know the game you’re making the map for, and know it well.
So working free-form has its advantages, creating a whimsical sense of liberation in the budding mapper. It comes at big costs to him, though, in other aspects. This open doorway, and the entire route it signified, never made it into the final product. People have noticed its conspicuous absence, however, to the point that it may make it's return soon enough.
Working toward a result, with certain restraints in mind, but willing to cut: my method for Museum.
Mistakes were made. Certain areas violated basic good-practice principles, such as this one:
I call this piece of modern art “Abstract Red Light Number 48.” So… this elevator shaft was painful for a few reasons: too noisy inside, not clear enough about what it was meant to be, and the idea of it having a purpose seemed impossible given the amount of crap stuffed into the scene.
I believe I settled on a better, cleaner result:
Which was based off of this reference:
This shipping area was another idea that got cut (considering that it was over-dark, this was not too sad):
Everything else seemed to go swimmingly, however:
My biggest advantage when working with these references is my ability — and perhaps your ability as well — to discern from them what elements are most relevant and work best geometrically. These judgements influence what makes it into the map. While you may be able to follow a similar protocol by examining the pictures, you would be doing so in hindsight; it was quite necessary during this project for me to be able to sift through literally thousands of images in order to find those which, at first glance, provided the requisite inspiration.
References must be clean, they must convey a certain tone, and the architecture they illustrate must be plausible among the rest of the map geometry. This process of looking through seemingly endless references is a task which must be begun anew with every new map.
Back on topic: a month or two after starting out on the map, I recruited a talented 2D artist named penE who had a style congruent with mine. With his help, rooms like this began to form their own identity:
The map began to develop a sense of humor. We based the name of the museum on HURG — Hero of MapCore! (Don't ask.)
PenE brought his full enthusiasm to the project, getting almost all of his work done in a month or so, a rapid pace which would be a major motivator for me while I was working with (read: waging war against) the Hammer editor.
Here is a sample of penE's work for the map:
Nevertheless, the map did seem to require more art…
I had envisioned a T-Rex in the above room, and had designed the room around that eventuality. I was concerned that such a 3D model might not fit well (it’s a relatively cramped room), or might not be appropriate looking, but I put out a call for a talented 3D artist.
3Dnj answered that call with a stunning T-Rex model based on square-shaped geometric restraints. I basically stacked a bunch of cubes on top of one another and said, “OK now make me a T-Rex that fits inside the squares.” Seems hopeless, right? Thankfully, Valentin, as 3Dnj is known, e-mailed me this bad boy:
Owns right? Imagine waking up and seeing that first image of the T-Rex with that brilliant sheen, I was ecstatic.
At that point I realized I’d found a true collaborator and not just a “prop guy”. Valentin would go on to help me optimize the map, and reform a lot of my map geometry into more sensible models. Here’s how crazy things had gotten:
Hammer is unlike a modeling program in that it is “brush-based”, and things that are not literally six-sided cubes give the editor trouble. Trying to create an interesting shape out of a single brush? Take a hike.
So it’s obvious why a more extensive collaboration was needed: it was never going to be realistic to proceed in such a manner and expect an optimized result which would (ugh) compile. Hence, the logic of making a map which looks the way Cabaret does, unfortunately all the same limitations applied more or less in 2012, with just a few exceptions like instances.
So there were technical challenges, but four months on, most of the major lessons of the map were learned and my vision for the map was realized almost exactly as it existed in my brain.
My workflow can be best summarized as: find a fitting photographic reference, get a basic interpretation of the geometry into the game, and then polish with aesthetics and navigation in mind (lead players with lights and colors).
Rather than attempt to convince you I pursued the traditional level-design approach of iterating a grey-box, I hope this document serves to explain the approach I actually took: a risky and improvisational one that I know I’m lucky was successful. It’s good to state how lucky: a layout that emerged without argument, finding two brilliant collaborators with a lot of faith in the project, etc. Hopefully anyone looking to duplicate my exact method will be given pause, but at the end of the day there will always be logic in working hard and having a well-formed mental image of your goal.
As for Museum, I can promise you one thing: if you load up the map, and I hope you will, I think you will enjoy it. (If only for the giant, motherfucking Tyrannosaurus Rex.)
Thanks for reading.
El Moroes 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)
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.
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!
El Moroes reacted to FMPONE for an article, Reddit + Mapcore CS:GO Mapping Contest!
(Art by Thurnip)
/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.
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.
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!
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.
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!
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.
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.
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)
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)
El Moroes reacted to FMPONE for an article, 2014: MapCore's Year in Review
Overview of 2014's articles We published a ton of high-quality, original content in 2014. Take a look — you might spot something you missed!
Interview with Mateusz 'seir' Piaskiewicz, Techland Senior Level Artist
Interview with Rosin 'kikette' Geoffrey, Arkane Studios Environment Artist
Deus Ex: Human Revolution scene interview with KNJ
Virtual Reality: The Final Platform
Interview with Francois 'Furyo' Roughol, BioShock Infinite Level Designer
Interview with Thibault 'dkm' Courbet, Wolfenstein: The New Order Level Designer
Interview with Lenz 'penE' Monath, Environment and Lighting/VFX Artist
Interview with Thiago 'Minos' Klafke, Blizzard Environment Artist
Interview with Paul 'PaulH' Haynes, Homefront: The Revolution Senior Level Designer
Korath: The Witcher Saga scene interview? with Krzysztof 'Tepcio' Teper
Level Design in The Last of Us: Part One, Part Two, Part Three
13,500+ reads (all parts)
Contests and challenges Even better, MapCore continues to thrive as a close-knit community. We collaborated, playtested one another's work, and inspired eachother. Thanks to RZL for his great work organizing Counter-Strike: Global Offensive playtests. SpronyvanJohnson also did a great job organizing MapCore contests, where users pushed themselves to improve their skill set.
We had a fantastic contest and two thrilling challenges, all of which received unprecedented levels of support and engagement. You can relive the action here:
Quake 3 15th Anniversary Contest
CS:GO Sticks Mini Texturing Challenge
New logo and branding For the first time since the forums were established in 2003, 2014 saw the introduction of professional-grade branding, which was brought to life by our very own Arthur de Padua (AKA Thurnip), including a wonderful new logo! We also set up a small store for those wishing to spread the wonder of MapCore throughout the world, complete with Arthur's beautiful new designs, and we'll be updating the store with even more new products based on your feedback very soon!
New logo and branding by Thurnip
Babies! MapCore kids were also born in 2014! ...God help us all. A huge congratulations to Skjalg and SpronyvanJohnson for their ultimate creative projects: bringing new life into the world. If we missed anyone, let us know in the comments so we can add you!
By 2-D Chris
Employment As a community, MapCore has always been a mixture of veteran game developers, aspiring amateurs, and plain ol' gamers. One of the best parts about that mixture of experience-levels is when one of our members gets an awesome new job within the industry. In 2014, we got a LOT of great news on that front.
Martin "Sentura" Colith - Level Designer at IO Interactive (Copenhagen, Denmark)
Al "Intelect0" Anselmo - QA Tester at Top Free Games (Sao Paulo, Brazil)
Lenz "penE" Monath - Environment Artist at Yager (Berlin, Germany)
Oskmos - FX Artist at DICE (Stockholm, Sweden)
Morten "Mazy"Hedegren - Game Designer at Brain+ (Copenhagen, Denmark)
Skjalg "Skjalg" Sturlasson Maehre - Programmer at Megapop Games (Drammen, Norway)
mr.P - Senior World Designer at Avalanche Studios (NYC, NY, USA)
Pete_H - Game Designer at Gameloft (Barcelona, Spain)
Jobye-Kyle "deceiver" Karmaker - Level Artist at Ubisoft Toronto (Canada)
Alex "AlexM" McGilvray - Build/Tools Engineer at United Front Games (Vancouver, Canada)
Alexander "Taylor" Taylor - Game Designer at Space Ape (London, England)
Kacper "knj" Niepokólczycki - Environment Artist at CD Projekt Red (Krakow, Poland)
John "Ginger Lord" Crewe - Senior Technical Designer at Cloud Imperium Games (Manchester, England)
Paul "PaulH" Haynes - Senior Level Designer at Deep Silver Dambuster Studios (Nottingham, England)
Toni "SotaPoika" Seppänen - Junior Level designer at Next Games (Helsinki, Finland)
Austin "Setin" House - Designer at Escalation Studios (Dallas, Tx, USA)
Richard "KoKo5oVaR" Malinar - Environment Artist at Krysalide (Lyon, France)
Mateusz "seir" Piaskiewicz - Designer at Treyarch (Santa Monica, California, USA)
Jason "General Vivi" Mojica - Senior Level Designer at Overkill Software (Stockholm, Sweden)
Will "Vilham" Josephy - Senior Level Designer at Cloud Imperium Games/Foundry 42 (Manchester, England)
Chris "2d-chris" Kay - Senior Level Designer at Epic Games (Cary, NC, USA)
Liam "PogoP" Tart - Environment Artist at The Creative Assembly (Horsham, England)
Matthew "bawwwcas" Barcas - Level Designer at Pure F.P.S. (Los Angeles, California, USA)
Francois "Furyo" Roughol - Senior Mission Designer at Sucker Punch Productions (Bellevue, Wa, USA
Friedrich "FrieChamp" Bode - Level Designer at Goodgame Studios (Hamburg, Germany)
Our members' success rate at having their content (gun skins, maps) added into Counter-Strike: Global Offensive also continued to be astronomical.
Wrap-up At the end of the day though, MapCore has always been about one thing: sharing work in progress, receiving feedback, and learning from one another. In 2014, MapCore's WIP threads buzzed with life and activity, and our 2D and 3D forums were a goldmine of beautiful work, interesting ideas and fun experimentation.
Our community is working better than ever, and 2015 should mark even further progress in the growth of this awesome forum.
SpronyvanJohnson's map given feedback in the form of an overpaint by Seir
El Moroes reacted to Furyo for an article, Level Design in The Last of Us: Part One
This is the first article in a three-part series. Part One / Part Two / Part Three
Intro Level 1st scene In typical movie fashion, the game starts with an exposition scene which establishes the bond between Joel and his daughter Sarah. Here the watch plays a type of backward MacGuffin (http://en.wikipedia.org/wiki/MacGuffin), which movie fans will be familiar with. A term made popular by Alfred Hitchcock, this initial narrative element will keep showing up in multiple scenes in the game to move the scenario forward and link back to the initial bond Joel had with his daughter. Many other items in this game, which we’ll see exposed in Sarah’s room play the same role. It’s important to note that this game doesn’t use forward MacGuffins, instead relying on the early experience players have with Joel in the intro levels to help them relate to Joel in the later parts of the game, when he faces adversity from the other main characters in the game. This type of catalyst is sometimes linked to gameplay in some games, but not here. For instance, in a quest, looking to get somewhere or obtain something but never managing to. In BioShock Infinite, Elizabeth keeps trying to go to Paris, but never quite goes there in the main game.
Gameplay Sarah goes to bed, only to be woken up by her Uncle Tommy’s phone call. The initial frame of Sarah getting up is a textbook example of player exposition. Using the mirror on the wall, Naughty Dog adds depth to the room, and presents Sarah as a playable character from both front and back. The color of the lamp shade also leaves nothing to chance. Using a warm color near her beloved items reinforces the comfort of her nest (bed) and contrasts heavily with the cold blue of the night in the mirror. These items on the wall, much like the watch earlier, play a narrative role in the rest of the game as tools to drive the scenario forward between Ellie and Joel.
Sound wise, Naughty Dog made a classic choice not to add any music and simply build tension with environment sounds in the background. It plays great and helps focus the attention on the initial reveals. In the room, the placement of the birthday card ties the opening scene with this scene the following morning and introduces the “triangle” button as the “hand interaction” one in the game (pick up item, open door, etc).
At this point in the game, the player still does not quite know what to do, despite having played for a few minutes already. This guidance is given very clearly in a single word, right outside Sarah’s bedroom, as she yells “Dad?”. Perfect example of narrative design coupled with level design, that tells the player his/her immediate goal, and invites him/her to check out every single door, increasing the chances for maximum exposition of every theme in this intro level.
With the goal now firmly established, the placement of the door straight ahead, too obvious, makes that room a natural space for continued exploration of the game’s themes, as opposed to a significant room. It comes as no surprise to find inside that room just one piece of content. The placement of the only light source in this room, obvious as it is, reminds us that lighting is one of the most straightforward tools to guide players.
Joel’s bedroom After leaving this bathroom, players are naturally directed towards Joel’s bedroom thanks to the window, extra light placed in front of it, and the barely open bedroom door. The sound of the TV is an ideal guidance tool, suggested instead of shown. This bedroom also offers the chance to see the gameplay loop closed for the first time. The Last of Us’ gameplay loop is always a variant on four themes: Exploration, Tension, Challenge, Reward, Return to Exploration. With the initial exploration started in Sarah’s room and the tension of having to find her dad, this room introduces the simplest of challenges – opening the door and following the gameplay instructions (L3) – which ends with an immediate reward of seeing the explosion in the distance. Finally, Sarah’s “Daaad?” closes the loop and makes players return to their exploration phase. Gameplay loops can express themselves over varying lengths. Second to second, minute to minute, hour to hour.
Returning to the hallway, a few classic LD rules can be seen in the same frame. The placement of the door allows players to face the staircase in the right direction, and the placement of the lamp at the bottom automatically invites players to go down. Notice its actual placement. While most times placing a light source away from a player’s immediate field of view increases its attraction, this one is placed to the right in plain sight of the player.
Once at the bottom of the stairs, the window introduces a new narrative element, in the form of police cars. Notice that the cars are driving in the same direction as the player needs to move. This is yet another good tool to guide players subconsciously. If the lamp at the bottom of the stairs had been placed to the left, and away from the player, he/she would have likely turned the camera towards it and away from the windows, negating the introduction of the police cars. That’s why this light source was better left in the player’s field of view.
Players naturally progress and now face this door to the garden, this time with a light source hidden beyond the playable space which naturally increases the mystery and tension in the scene. Just like upstairs in Joel’s bedroom with the TV, the dog barking here increases tension and attracts players forward.
Once players reach the window, Naughty Dog doesn’t fall for the cliché of having an infected appear in the garden, and plays with players expectations instead interrupting the sequence with Joel’s phone. Doing so, “L3” is introduced again this time on the player’s critical path to make sure this mechanic is understood by all players.
The placement of the phone to the right of the door is also no accident. It makes players move further away and to the other side of the living room from the office, where players are now supposed to go. This forces players to go by the garden window a second time and the use of the phone has forced the player’s immediate attention of the window to be erased. This perfect set up was necessary to create an element of surprise for the second traversal of the living room.
Narrative scene and transition A sign of truly great narrative games is the justification of every single camera takeover by placing the played character in a situation that allows for a smooth transition. Here, that’s the only reason this half open door is placed here. Since it’s already half open, like Joel’s bedroom door, there is no “triangle” interaction required. The goal of this door is to justify the exact position of Sarah in her animated entrance into the room, therefore the position of the camera, to allow for a smooth take over for the rest of the cinematic and the entrance and reveal of Joel, the very first in the game.
While the entire scene could have played out inside Joel’s office, Naughty Dog chose to have Sarah and Joel leave the office half way through, so as to cut back the length of the walk to the exit door and outside to the car. This allowed them to shave off a few seconds of otherwise boring content and make the action denser. Uncle Tommy’s introduction is pretty hectic with the rapid movements and a lot of information handed to the player, so to reinforce his presentation, Naughty Dog chose to have him turn towards the player once inside the car.
The Last of Us, as many narrative games, presents choices to the player. They come in two types, active and inactive. Active choices are generally self-explanatory and are not even presented as such in games. For instance, play style (stealth or action) influences the outcome of fights, but they can also come in the form of a single button press, which usually destroys immersion in a world, and breaks the fourth wall. Inactive choices on the other hand play with morals and psychology between players and the characters they play. Here we see the first glimpse of the troublesome relationship to come between Joel and Ellie, in the eyes of her daughter Sarah who wishes that the car had stopped to help the stranded survivors. This makes players ask themselves where they would stand, and take sides with the future protagonists.
The accident serves here as a transition and justifies leaving the car behind. The timing of that sequence is probably not purely by chance. First Naughty Dog had illustrated all the themes they could from inside the car, and second the attention span of test players was probably waning beyond that point. Notice however the subtle and progressive introduction of infected in the world. The first one, inside Joel’s office comes in when they may yet be taken for humans, and as an element of a cinematic, it offers no challenge to the player. The second, in this car sequence, attacked other survivors and when posing an immediate threat to Sarah, was stopped by Tommy driving away. The third, much closer view comes in as a direct consequence of the car crash. These three progressive introductions of the game’s main antagonist are a textbook example of exposition that allows players to fully grasp the concept of the infected before having to deal with them. Many games fail to present enemies that way, instead relying on one-shot cinematics with poorly explained antics and backstory. The fact these enemies can’t talk and explain themselves pushed Naughty Dog to work them this way into the game, to great effect.
Combat Tutorial First introduction of the « Square » button for combat. As a rule, tutorials are better introduced when players attention span can be solely directed at the mechanic in question. Here, the tension resulting from the car accident and the sight of the infected nearby focuses the player’s attention on the tutorial for maximum effectiveness. Instead of breaking the immersion of the scene, this tutorial actually flows inside it, and players never question it. Naughty Dog’s choice for minimal UI invasion on the screen really pays off here.
Chase sequence Introducing Joel for the first time as a playable character (and the main protagonist) in the middle of a stressful situation could have been a risky proposal, which Naughty Dog managed to make work by taking away all combat (automatic death if caught by infected and gun given away to Tommy). Sarah, who would have trailed behind and become a center of attention for players is reunited with her dad after getting hurt in the accident. All of these moves act as perfect justification to have players only ever care about their own character. The only action required of the player is to dodge pedestrians, which is exactly the best activity to learn to control a brand new character. The use of a car that crashes into the gas station is a bit of a cliché by now, but remains a very strong justification for sending the player to the right, and have a couple invisible walls across the other streets. It remains better than a simple static object across the street and infinitely better than nothing at all.
The firemen truck across the street serves both as justification for the fire raging in the building next door, and as a way to direct the player to the car crash about to block the street off. This second instance however occurs much closer to the player, increasing tension further, and culminating with stopping in front of the theater beyond. This “three strikes” approach to game design is rampant through most games these days, and certainly The Last of Us, for instance during the combat tutorial (three square button presses to leave the car) and is a sort of golden number first generalized by Nintendo.
The use of audio after the third street blockage is mandatory given the exit is not readily apparent within a 45 degree field of view on either side of the theater. In third person games, presenting exits within this 90 degree angle is generally considered a safe choice to have players flow, on consoles at least where the FOV is usually limited more than on PC games. For instance, this was the rule we followed when designing Prince of Persia in 2008.
In the alley and through to the other side, great use if not subtle of lighting to direct players to the left, and first use of the yellow color on all directional and interactive hints, which we’ll see later in the first level. We’ll find the same use for the ambulance down below, which strong red lights contrast easily with the night, and even the wind indicating the sense of direction. The headlights serve as guidance too of course, much like the hurt survivor on the ground.
This is the first article in a three-part series. Part One / Part Two / Part Three
El Moroes reacted to Thrik for an article, Announcing the UE4 Whitebox Challenge winner!
DM-Helium by Chris '2d-chris' Kay
Congratulations! While no prizes were planned, Chris will receive a special winner's T-shirt for his efforts. It's truly a gorgeous map, although it's in good company as all entries were of a high standard. The community has some great maps to play on right here, and I've no doubt that we'll be seeing more of them in playtests and on servers.
The challenge was fascinating to watch, with the filled with shots of the in-development maps and — perhaps more importantly — members helping one another to create some sweet Unreal Engine 4 levels. In fact, this part of the challenge was so interesting to follow as a non-participant that we're going to try and make the in-development phase of future challenges more prominent by following the progress with articles taking a look at how things are going.
The official Unreal Tournament site picked up on our challenge by talking about it for a few minutes at the beginning of the challenge, and while they briefly acknowledged the end of the challenge in a more recent stream they're apparently still checking out all the maps and will be featuring them more shortly — so stay tuned for that!
I'd like to thank everyone for their involvement, and I sincerely hope that everyone had a good time experimenting with an engine iteration that's still new to most people. Be sure to head over to the to check out and download all of the levels!
We don't mess around at MapCore and want to get one more event in before the year ends, so we're going to be kicking off a Quake 3 contest very soon — this time with substantial prizes, just to spice things up a bit! Hang tight for details about that.
El Moroes reacted to Thrik for an article, Interview with Jean-Paul Jarreau, Black Mesa level designer
Tell us a little about yourself. Where do you live, and what's your day job? Oh man. I unfortunately live in Rochester NY (no its not driving distance from NYC) and am currently unemployed. I graduated college with a degree in Photography and a minor in Philosophy in 2011 and worked for my step father's company until july of this last summer. So I currently spend all my time working on levels and photography, I honestly cannot complain right now.
When and why did you decide you wanted to bring worlds to life in 3D? When I was 14 I had a passion — playing games. I loved it, it sparked something inside me and I had no idea what it was, but I liked it. My personality can be pretty analytical at times so naturally I tried to figure out how to make them. I love architecture, buildings and 3D space, so I just went for it. I spent hours and hours in every level editor I could find and I, admittedly, stuck with hammer because it was the easiest to pick up, had the largest support and the biggest community. I've been with it since. That's what, 9 years? 9 years of blue screens and move_rope causing crashes straight to the desktop — it's a love–hate relationship.
How did you get involved with Black Mesa? This is funny considering the level of amateur crap I have made. I applied to Black Mesa back in 2004/2005 by sending a VMF to the founder of Black Mesa (Jon) of my recreation of the first Power Up level. It was a mess and ugly as sin. I had quite literally no idea what I was doing, but it was satisfying to create, so I kept with it. I clearly remember Jon's words: "It looks, eh, amateurish". So, I spent the next few weeks refining my work and I applied a few other times. I eventually got on the team and I started work from there. I remember a good friend of mine, Daniel Junek, was already on the team and when I loaded up the private developer forums and saw his orange map layout of the blast pit silo, immediately knew I was going to be on the team for a long ass time — I saw what COULD be Black Mesa and was instantly inspired.
Funny story: I always considered Daniel's work (he did Blast Pit) to be godlike, it was just incredible, I had never seen anything of such quality and ridiculous planning and care. I have this habit of comparing anything I do to the current best work in the world so I know how to improve myself and I considered Daniel's work to be the best in the world. So, naturally, I compared my work to Daniel's and for years it never even compared, but I was slowly getting there. So, a few months ago I, slightly buzzed, messaged Daniel on steam and came to realize he did the same thing with my work this entire time.
I joined the team and looked at what was available to work on and I, of course, had to pick Lambda Core. I had no idea what I was doing and some of the early parts of Lambda Core show that.
What was it like getting to reimagine the world that kicked off many MapCore members' interest in level design? Oh wow I never thought of it this way. Want to hear something hilarious? Before getting on the Black Mesa team I had never played Half-Life before aside from one or two killbox matches on a friends computer.
But as for re-imagining a world that so many hold dear? Its a difficult process, at least for me. I wanted to strike people on an emotional level with my work, I wanted people to see certain things I made and say "Holy shit, this is amazing", and while I don't know if I have accomplished that or not, I do know that getting there was an intense process.
I remember loading up a Lambda Core map and thinking to myself, "What makes this interesting? What makes this bad? What makes this fun? What makes this area instantly recognizable? How do I create something in the present that completely awed those in the past? It was honestly tough in certain parts and I can remember re-doing sooooo many parts of the game because I personally thought it didn't hold up to any creative scrutiny.
Were you often tempted to take a whole new approach to parts of the game? How did you find the right balance of old and new? This is a good question and I bet some die hard Half-Life fans still think we screwed up parts of the game haha. For me it was mostly taking a look at the original and what it tried to accomplish and improving on that. Sometimes certain areas didn't even need improvement, it just needed refinement, an extra level of polish to really take home its intended goal. When there was a controversy over what should be done in the game, we would just look at the 'numbers'. Did a majority of Half-Life players like this certain area? If not just scrap it and try again but be sure to retain the original's emotional impact on the player.
Did it ever feel like Black Mesa might never make it? Was your motivation affected? More than you can ever imagine. We worked on it for about 9 years remember! Honestly? It probably felt like we weren't going to make a release more than we were going to make a release. There were periods of inactivity on our developer forums for months at a time. We all have personal lives to attend to and sometimes it would be a perfect storm of events where no one would work on anything for extended periods of time. Then, out of nowhere, something would happen and everyone would get sparked and jump right back in and get loads of work done for months. Rinse and repeat.
In the SUPER early stages of development there was a point where we didn't even have a coder for 2 years. You can only imagine how incentive was on the team at that point.
There's still a significant portion of Black Mesa yet to be completed. Will it be purely new material when the remainder is released, or are you revisiting and/or expanding existing material? I will answer with a simple work-in-progress screenshot of something I am working on and nothing else:
What do you think is a stand-out part of Black Mesa? I have actually never thought about this! But the FIRST thing that jumped into my head is when you first enter the turn-table room in Power Up. You witness an intense fight between a Gargantua and a few human grunts. It's incredible because of the collaborative effort that went into it without a single f**king hitch. It's like it was done by one person! Let me explain:
You enter a beautifully themed section of the facility created by Daniel Junek You witness well crafted animation by Nate of the Garg getting blasted by a human grunt and consequently falling into and breaking the concrete wall near him. The Garg was made by Chris The surrounding textures are made by Mark The dead human grunt bodies turning into scorched corpses, the flame effects, and the Garg behavior was done by Paul and Mark All the sound was done by Joel Look at that! It's the personal work and vision of a team of people all together forming a unified and impressive quality of interactive work. It wouldn't even be possible to create something that well done by one person.
Now you may say "Hey, thats how all games are made." But, its a little different when you are creating something of this size and scope and all you have to communicate with your co-workers is Skype and a forum. There were a lot of times when I would be making a gesture with my hand or something while trying to describe the way I want a prop or texture to look. That was frustrating.
You do a lot of multiplayer level design in addition to your single-player work. Which do you prefer? Single player is telling a story and using the environment to make playing the story fun and visually interesting while guiding the player through a struggle. If you can hold a player's attention and feed them the facts then you are good to go. Multiplayer is about cohesive design and fun welding itself into one entity and that can be difficult at times. Honestly I probably prefer the multiplayer work because of repetition. You know players will be running around your environments thousands of times which will eventually lead to an appreciation for the map on tiers usually only seen by the actual level designer. That is a double edge sword though.
Briefly, what's your general workflow for putting a level together? LAYOUT, LAYOUT, LAYOUT. I try to get simplistic layout for a map that is fun and cohesive before doing anything else. Why do you play a video game? Because it's fun, and as a level designer, that fun can be directly proportional to your quality of work. You are almost like a spokesperson of your entire team's work and I love it. I mean I could tell you about all my thought processes while I work but that isn't as fun. But, I usually tend to think of ideas in a 3D space, so I never really draw layouts, I usually just throw some brushes around to get my idea out of my head and see what can be made of it before I attempt any sort of real layout. A lot of my past ideas failed even before getting to the layout stage, so that is good (I think).
Which bit of the process is your favourite? That part in a map's life right as you know everything is fun and you get to unleash your thematic ideas you had been planning in your head while working on the gameplay and layout.
And your least favourite? Any sort of tedious mind numbing repetition is annoying. Or when you spend a long ass time solving a problem in your level only to have it come out like crap but its 5am and you have to go to sleep knowing what you just created is terrible. That's no fun for anyone.
What's the hardest problem you've encountered while mapping? Writers block can apply to anything really. There were times where I would just stare blankly at a map for hours not knowing what to do. Recently though? I cant stop with my ideas, it's great. I'm trying to ride that wave for a little.
Also, scrapping something you have put a massive amount of effort into can be disheartening but it has to happen sometimes. But what essentially is anything creative? It's the formation of an idea while hiding your influences. Sometimes these ideas need to go through an emotional struggle before work can continue.
Which piece of level design are you most proud of? To date, my Black Mesa magnum opus is most definitely the final Lambda Core teleporter and its prior lower reactors. Fun fact I thought some designers might appreciate: the entire Lambda Core reactor and teleporter actually lines up like an actual facility if you copy all the maps into one file and place them correctly.
More recently? It's my map cp_imbricatus for Team Fortress 2. I have a feeling that the map will fundamentally change the way a good three-control-point attack/defend map should play.
In addition to level design, you're an accomplished photographer. How did that begin? Accomplished? Oh you. Thanks, you.
Here is a story I have never really told anyone haha. I was an idiot in high school, I mean who wasn't? But when it came time to apply for colleges, I just straight up didn't make the cut. I applied to stupid high reach schools and nothing else, I think I even applied to the wrong program in a few schools. Needless to say, I didn't get in anywhere and I panicked. My mother had some connections at Rochester Institute of Technology and randomly one day called me while I was out and asked me a few questions:
She said, "I got you into RIT and their photo program doesnt require a portfolio, which would you like to do? Fine art, photojournalism, advertising or biomedical photography?" I got lucky and I knew it. I wound up graduating with a bachelors of fine art in advertising photography. Crazy.
A lot of your photos are taken in very challenging conditions, such as live music performances. What skills and equipment do you employ to get such great results? Simplicity is key. Both visually and philosophically.
You must look at every situation like you are the one viewing the content with no prior context as to what is going on. Do you want to portray a story? Do you want to create something purely for its visual content? What's your end goal? I could honestly talk about this for hours.
I currently only use a Canon 5D Mark 3 and the only lens you ever need — a prime 35mm f/1.4. A good photographer with a bad camera is going to make better pictures than a bad photographer with a good camera. I also adhere myself to a lot of personal restrictions (in level design as well). An example being I never crop any of my images, I always thought it was best to just leave it straight out of camera. I do Photoshop my images, but I don't crop them. (Note: if you are a client that hired me as a photographer, I will do anything you want to the images if you request it. These rules usually only apply to personal work.)
Keep an eye out on my Tumblr for some new photography coming up soon.
Do you find that your photography skills bleed into your level design? For example, when composing scenes? Absolutely! And it works both ways too, photography helps my level design and level design helps my photography. Lighting plays a more important role in both than most even think. I am just lucky to have experience in both.
I don't want to toot my own horn here but look at the lighting in some of the reactor areas in Lambda Core. It got to the point where I set 50% and 100% falloff distances with a hard cut-off for the yellow lights surrounding the central cylinder so the centre reactor would ominously glow yellow without casting any mood changing light onto the surrounding geometry. Does that level of detail pay off in the end? I don't know but I hope so.
What games would you say have inspired you the most? I have never thought about this before but here is a list of the first games I can think of to inspire me:
Ocarina of Time: Video game perfection. Majora's Mask: I cannot even put into words the impact this had on me Wind Waker: How do they even make this stuff? It's like they converted crack cocaine into playable form. Half-Life: Was I obligated to say this? This game changed what a first person shooter could be with its incredibly inventive layouts and story telling. Painkiller: The basic first person shooter mechanics perfected and in gory glory too. Incredible environment art to boot as well. Banjo-Tooie: Incredible game design, just incredible. Battlefield 2: The amount of serotonin released in my brain by playing this game should be illegal. Super Mario 64: An amazing sandbox game before that term ruined a lot of modern day games. Far Cry: It materialised my emotions while playing a game by me actually muttering the word 'wow' while playing in certain spots. There are loads more but these are just what I could think of off the top of my head.
If you could give a budding level designer a short piece of advice to help them succeed, what would it be? Your work is going to suck for a long time, get used to it. If someone is being a dick about your work, they probably have a good point. Listen to them without bias. This will push you beyond what you thought you were capable of. You made the level, no s**t its easy to understand by you — other people HAVE to play it before anything is considered good. Scale will make or break you. Do a lot of scaling tests in every game you want to develop for before attempting anything else.
MapCore would like to thank Jean-Paul for his time, and wish him the best of luck with his future projects. You can enjoy more of his work by visiting his portfolio and Tumblr. He's also looking for people to help out with testing his latest Team Fortress 2 map; simply download 'cp_imbricatus', take a peek at the
and join in on the tf2maps.net server.
El Moroes reacted to Froyok for an article, Technical breakdown: Assassin's Creed II
The following breakdown is based on my own guesses and how I understand the game from the textures and meshes I have watched. I can't tell you exactly if I'm right or wrong since I'm not a developer of the game. However, I believe I'm rational enough to think that most of what I say is close to what the developers have done. The purpose of this breakdown is educational and the work presented here belongs to its respective authors.
Anvil engine The Anvil Engine is a proprietary game engine used by Ubisoft's game projects for a few years now (the first game using it came out in 2007). We can call the Anvil Engine a next-gen engine since games for the previous console generation (like the Playstation 2) were using the Jade Engine at Ubisoft. The first project using this engine was the first Assassin's Creed game. Its initial engine name was Scimitar (before the release of the first game). Today, eight games are using this engine.
The engine has since been updated with Assassin's creed III under the name 'AnvilNext'. Mostly to support the new game challenges and configurations that we have today and probably to be ready with the future game consoles coming along.
Atlas and batching As with every open world and/or huge city, you have to deal with a very high number of resources. Mostly to keep the player in a fresh world and avoid repetitions. Games over the years have used various techniques to get past this problem. One of them is to reuse any resources that you have created. Creating a texture for only one object in this type of environment can be a problem in term of memory footprint. So reusing a texture will allow you to keep you memory low in size. Pretty obvious, however it's a hard balance that you have to deal with: diversity versus quantity.
The size of the memory is not the only problem that you will meet; the number of drawcalls is also very important. As a reminder, a drawcall is a call to the API (the functions of the GPU to draw a set of primitives). For each frame that you render, you have a certain number of drawcalls. Each time you call the API to draw something it takes a given time, regardless of what you want to draw. So you want to be sure to reduce these calls to avoid any loss of performance (taking too much time to draw a frame will reduce your number of frames per second).
Each time you change a mesh for a new one you will create a new drawcall, because for the engine it's not the same geometry. This rule applies for the shaders too. If you change the shader, you don't render the same thing, so you have to change the way you render it. This means a new API call.
A common solution to this is to batch your calls. 'Batching' means to group some meshes together before calling the API to draw them. This is why it takes less time to render a big mesh than multiple small meshes. How to batch these meshes if chosen by the engine, there is no best rule for this and it depends a lot of what you want to draw. In the case of the Anvil engine, you are focused on drawing large and open spaces. The best way to improve the performance in this case is probably to batch per shader. So each geometry using the same shader will be sent together to be rendered. This way, reusing textures will allow you to batch a lot of things and gain a lot of time.
So using atlas textures (multiple textures merged as one) will be a great benefit: you will reduce your memory footprint and you will use only one shader for multiple objects showing different things. Assassin's Creed II uses this system a lot for the environment and the characters. Since we evolve in cities, some houses are often similar, it is logical to find the same design multiple times. Which means that reusing a texture would not shock the player. It will even help for the visual consistency of the level. However, I believe that the engine was not perfect and due to some performance problems (maybe because of the dynamic lighting) they limited the number of textures. In Venice for example, you have an average of 1500/2000 textures in memory (including everything: sky, water, normal maps, shadows, characters and so on).
What do the textures look like exactly? In this game, textures for the walls are often around 512 x 512 pixels. Details, ornaments, water use 256 x 256 pixels most of the time. For example, the roof texture is only 256 x 256, but the tilling is so well made that it doesn't gene at all.
However, these textures being very tiny, the developers used vertex painting to blend details and break the repetition. Since there are almost no specular reflections in the game (probably to strengthen the feeling of the walls are made of bricks and dirt) the vertex painting masks are stored in the alpha channel of the diffuse texture. As you can see in the second screenshot below, the alpha mask uses very defined greyscales, probably because they separate each level of grey as a separate filter.
The textures are very bright, and we feel that in-game: the overall lighting is itself very luminous.
Levels of details Dealing with an open world means dealing with a very long view distance. Therefore, the farther you see, the more you need to draw. Unfortunately you are limited by the hardware (especially on consoles) and you will have to use some LODs (level of detail). The developers have chosen to let the LODs 'pop'; this means no blending transitions between them, which is visually ugly since you notice the change.
The environment collisions are dissociated from the visuals mesh. Probably because you can more quickly hide/disable the collisions of the environment since they are not visually displayed on the screen. This explains why forcing the LODs of the environment allows you to... climb the void!
On the PC version, you can increase the minimum distance for when the environment starts to blend (which is something like 40/50 meters if you blend at the furthest possible distance). It's also interesting to note that some props like barrels, crates and other little things are independent of the global LOD distance. It seems that some props are linked to the LOD of the building mostly because they are at the roof level, while props in the street have their own blend distance.
Characters Pedestrians in Assassin's Creed are based on modular characters. The developers use a set of heads which are combined with hands and different clothes. While the hand and heads have their own details and colours, the clothes are just a totally grey shared texture (except for the letter) and coloured in the shader to add variety in the game. They also add a detail texture to break the linearity of the clothes and bring up some fine details. Characters have also their own LODs.
During a presentation at GDC 2008 about the first Assassin's Creed, Francois Levesque (a technical director on the game) explained their pipeline to produce a lot of different characters without losing too much time. They used a base head which blends to fit to the high-res character. This way they automatically get the LOD mesh at the same time since the meshes always shared the same topology. The only update to do was for the position of the bones on the top of the vertex to keep their skin deformation.
Since meshes and UVs are similar, it's easier to manage and create a crowd dynamically. So there are maybe 5–10 different clothes and then the game dynamically creates a character to add it in the game scene. In the first Assassin's Creed, characters had 2 LODs, which meant 3 meshes per character. In Assassin's Creed II it's the same thing. However it seems that the clothes and the head don't blend at the same time. Probably because they don't have the same space occupied on the screen. So the heads go to their first LOD mesh sooner.
You can see some examples on zBrushCentral with the base mesh topology and also the topology of some bodies used by the game.
Lighting The Anvil engine is an engine developed to mostly show open environments. With the development on this second opus, they wanted to add a day-and-night cycle. To achieve this they naturally chose the cascaded shadow maps technique (more exactly, Parallel-Split Shadow Maps as described in a GameDev.net forum thread) which even today is the best way to draw a unified shadow on such big environments.
There is no Global illumination at all, it's mostly only a main directional light (the Sun) combined with an ambient colour which evolves during the day. Some interiors like the tombs present localised point lights; there are also some point lights which are enabled during the night.
However, regarding the performance, they were obliged to use a very low resolution and a blend distance. This explains why you see a lot of blurred pixels on the ground/walls for the shadow. This is also why you so clearly see the blending of the shadow from one level to another.
Some shaders use the Fresnel term to enhance the looking of the character clothes a bit, but most of the time they simply use direct lighting without complex shaders (again, because it was very expensive). There is no fake sub-surface scattering (SSS) for the characters, even during the cinematics. The SSS only comes in with Assassin's Creed: Revelations and will be improved for Assassin's Creed III.
Conclusion Assassin's Creed II was a really good improvement compared to the first game, however it looks like the engine faced a lot of new constraints which were not totally well handled. The way the LODs appear and the nice but still limited quality of the lighting are good examples of that. Even on modern computers today the game gets some slow-down in certain places.
The engine was improved for the next game iterations and increased the amount of details and the quality of its lighting to finally show beautiful cities as we can see in Assassin's Creed III today.