jackophant

(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
by Squad
 

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
by marnamai
 

Counter-Strike: Global Offensive - Studio
by ZelZStorm, TanookiSuit3 and Hollandje
 

Portal 2 - Refraction
by Stract
 

Counter Strike: Global Offensive - Breach
by Yanzl and Puddy
 

Counter-Strike: Global Offensive - Berth
by grapen
 

Counter-Strike: Global Offensive - Kaizen
by Andre Valera and Jakuza
 

Counter-Strike: Global Offensive - Asylum
by Libertines
 

Half-Life 2: Episode 2 - FusionVille: The Shadow over Ravensmouth
by Klems
 

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
by Serialmapper
 

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
by Corvus
 

Counter-Strike: Global Offensive - Subzero
by FMPONE
 

Counter-Strike: Global Offensive - Biome
by jd40

What is the question?
Ever since the dawn of humanity, this question was the center of a colossal debate. Greek and Roman philosophers tried to solve it to no avail. Alchemists in the Middle Ages gave it a go and failed miserably. Even Industrial Age scientists touched on the subject with no big breakthrough.
Luckily for everyone, I am here today to answer this question and put an end to a centuries-long argument: What is better in terms of fps, func_detail or displacement, in the context of the Source engine? If you were expecting an existential question, I am deeply sorry to disappoint you but hey, life is full of disappointment.
The study
This is going to be a short but sweet article; fewer words, more numbers and screenshots. The study is pretty straightforward and systematic. To make things fair and square, I will create 2 exactly identical test maps: In one, everything will be turned to func_detail while the other will have everything switched to displacements. I will then proceed to record the localized fps in these maps from a preset location and compare. Pretty simple, isn’t it? Well, it should be as the whole purpose of this study is to compare func_detail vs. displacement in absolute terms while keeping all other parameters constant.
The cases
The first map to test is the one made of displacements. Here is the screenshot showcasing the fps.

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

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

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

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

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

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

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

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

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

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

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

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

You can notice the fps gap between the func_detail and displacement versions in both test maps whereas the “mixed” version considerably narrowed this gap. The numbers have spoken.
The bottom line
The bottom line is, if you rely only on func_detail, you will hit the maximum brush-count allowed in Source and severely limit your map and creativity. You might also run into T-junction issues as well as parts of your geometry flickering and disappearing from certain angles in densely func_detail’ed areas.
On the other side, if you stick to displacements alone, then you will have lower fps than a func_detail map version. You might also run into visible seams and un-sewn displacement issues.
Having a clever distribution of both func_detail and displacement in your map is the way to go. You will have high fps, better lighting around the edges, and organic sculpting while not getting anywhere near the total brush limit; the best of both worlds.
 

(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
Articles
High-quality original content:






Grand Prize Winner Announced


Hurg Smiles Upon You All!
 
 

This level design article is about the past and the present of the hostage rescue mode in Counter-Strike. Showcasing the inherent issues that accompanied the scenario allowing the bomb/defuse mode to gain traction and popularity. This article will also present what can be done, level design wise, to remedy some of the shortfalls and allow the scenario to be viable.
A historical background
Counter-Strike officially started life in June 1999 with the release of beta 1, and it shipped with four maps, that’s right, four whole maps. They were all hostage rescue maps and the prefix used for these maps was cs_ as opposed to the standard deathmatch maps starting with dm_. This prefix was an abbreviation of the game’s name (Counter-Strike) which hints to this hostage-rescue scenario being the only one in the minds of Gooseman and Cliffe, the creators of CS, at the time of launch.
Fast forward a couple of months, beta 4 rolled out in November 1999 bringing to the table a new scenario, bomb defuse. The new maps carried the prefix de_ and while one would think that the hostage rescue maps would be switched to hr_ prefix, they kept the same prefix which started to be referred to as the “Classic Scenario”. Counter-Strike was built on hostage rescue scenario.
I started playing CS in beta 2 in August 1999 (I totally missed beta 1, screw me) and maps like Assault and Siege were all the rage at LAN parties. The nearest LAN/internet café was a 5-minute drive from my place, and LAN parties with friends used to be a blast full of shouting, cursing, bluffing, noob-trashing; the standard menu for a CS session. Good times.
Siege, the oldest CS map (beta 1), and Assault (beta 1.1) were the epitome of the game. You had to dive in as a CT deep into the T stronghold to rescue the hostages and bring them back to safety. These maps were the most played on LANs and embodied the style of early CS gameplay. At the LAN place where I used to wage my virtual battles, Assault equaled CS, literally. A fun fact is that when Dust came out, I started a LAN session with this map and everyone in the room shouted at me: "What the hell is this? We wanna play CS!" For my friends, Assault was CS.
However, those rosy days for hostage rescue began to turn into grim grey when folks started playing bomb defuse scenario and realized how…fun it was. A map like Dust almost single-handedly pushed the scenario into higher ground with its bright environment/textures, clear/wide paths and its ease of use and noob-friendliness. A year later, around Summer 2000, Counter-Strike was now equivalent to Dust for my friends.
How did this happen? What went wrong?
Inherent flaws of hostage rescue
Hostage rescue is a very delicate and tough scenario for law enforcement operators in the real world. It puts the assailing team at a great disadvantage against heavily-armed barricaded hostage-takers who are probably using civilian hostages as human shields and as a bargaining chip for a later escape.
As you can deduce, transferring this scenario as realistically as possible into the game will not fare well, and this disadvantage will carry on for the CT team. The problem is only exacerbated when you add the more or less “flawed” game mechanics to the scenario. This is exactly what went wrong with hostage rescue scenario in case you are still wondering about the rhetoric questions at the end of the historical background introduction. The popularity of cs_ scenario started dwindling and the rise of the bomb/defuse scenario only made things worse.
Almost all the early cs_ maps featured a relatively tiny hostage zone/room having one entryway usually sealed with closed doors that the CT must open to get access inside. This room was typically located behind T spawn which made the area a camping ground and made camping that zone an obvious and rewarding tactic for Ts. The doors having to be manually opened with a loudening sound made things worse and negated any surprise or sneaky rush towards the hostages. A classic example is the hostage area and T spawn in cs_assault.

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

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

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

Showcase of Hostage Zone A on the map "cs_calm"
The above screenshot showcases “Hostage Zone A” in cs_calm. A terrorist will typically camp near the hostage covering the two encircled entrances. The third entrance from upper level denoted by the arrow is not in the direct FOV, and is prone to a surprise attack by CTs that could catch the camping T off guard. If possible, try to spread the entrances on different vertical levels to spice things up and keep Ts on their toes.
Lastly, it is a good idea to have a connector between hostage zones to allow fast rotations but without having a direct line of sight between hostage zones. We want to make the scenario fairer to CTs but not at the expense of Ts, inadvertently making it unfair for them.
Conclusion
Hostage rescue is a fun scenario if you ask me. It had many inherited and added flaws that contributed to its waning but it’s nothing that can’t be reversed. We, as level designers, need to push some changes to put the scenario back on track. What I just showcased in this article might not be the only viable solutions but they certainly are a step in the right direction. Level designers are intimidated by players who shun away from cs_ maps, and this turns into a vicious circle where players avoid hostage rescue maps and mappers in return avoid designing them. We need to break this cycle and designers need to bravely embrace the solutions I presented here or come up with their own solutions. The more cs_ maps that come out and get tested, the more we could validate these solutions as viable.
In either case, we need to get proactive towards hostage rescue scenario; after all, this is the cornerstone that Counter-Strike was built upon.

(Art by Thurnip)
 
It's Time!
It’s finally time to declare a grand prize winner in our exciting Counter-Strike: Global Offensive mapping contest. You’ve playtested the maps on Reddit, you've waited months for the results... let's get down to business!!
 
 
 
GRAND PRIZE WINNER:
 
DE_EMPIRE
By Andre Valera

Workshop Link
 
Sometimes it boils down to consistency: broad strength across several categories. No map in our contest better exemplifies this notion of consistent quality than Empire.
Empire features a stacked bomb-site layout similar to popular official maps like Nuke and Overpass. While this relatively unorthodox design presents level designers with additional challenges, Empire ably sticks its landing. Furthermore, the ambition of Empire’s design is tempered well by its no-nonsense visual presentation. We’re left with a digestible, fun, and very playable level.
 
Congratulations, Andre Valera!
 
Prize:
Featured in a goRGNtv showmatch!
Featured in CEVO PUG rotation for one month!
$1000 and Mapcore swag!
CS:GO prize pack courtesy of Valve:
a signed CS:GO poster, lanyard, vinyl sticker
SteelSeries Kana Mouse!
 
 
2nd PLACE:
DE_BOURG
by Klems

Workshop Link
 
A truly unique map. Some felt it was the strongest entry in the contest given its strong theme, abundant polish, and beautiful visuals; others, however, questioned the map's small scale. This was a tough map to judge.  
 
 
Prize:
$400!
CS:GO prize pack courtesy of Valve: 
a signed CS:GO poster, lanyard, vinyl sticker
 
 
3rd PLACE:
DE_ROYAL
By Jakuza

Workshop Link
 
An attractively sleek map, there is plenty of room for Royal to blossom into something very special. 
 
Prize:
$200!
CS:GO prize pack courtesy of Valve: 
a signed CS:GO poster, lanyard, vinyl sticker
 
 
4th PLACE:
DE_COAST
By Ornate Baboon

Workshop Link
 
A map that was under heavy construction for much of our contest, one gets the sense that Coast wasn't quite ready yet. With a little bit more time, who knows?
 
Prize:
$100 + Mapcore swag!
CS:GO prize pack courtesy of Valve: 
a signed CS:GO poster, lanyard, vinyl sticker
 
 
~~~We at Mapcore would like to thank the r/GlobalOffensive moderators for their assistance, our lovely guest judges, Valve, goRGNtv, CEVO, as well as Gamebanana.com and Steam workshop artist EGO DEATH for contributing to our prize pool.
 
Last but not least... THANK YOU, for making this 'Core event special and fun!
 
 
"May Hurg guide you..."
 

This is the second part of a technical analysis about Source Lighting, if you haven’t read the first part yet, you can find it here. 
Last time, we studied the lightmaps, how they are baked and how VRAD handles the light travel through space. We ended the part 1 with an explanation of what the Constant-Linear-Quadratic Falloff system is, with a website that allows you to play with these variables and see how lighting falloff reacts to them. We will now continue with basic examples of things you can do with these variables. 
 
Examples of application
Constant falloff
The simplest type of falloff is the 100% constant one. Whatever the distance is, the lighting has theoretically the same intensity. This is the kind of (non-)falloff used for the sun lighting, it is so far away from the map area, that light rays are supposed to be parallel and light keep its intensity. Constant falloff is also useful for fake lights, lights with a very low brightness but that are here to brighten up the area.
 
 

 
Linear falloff

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

 
Quadratic falloff

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

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

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

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

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

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

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

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

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

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

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

Since cascaded shadows and projected textures share some technology, you can’t use them both at the same time.
 
Conclusion
I really hope you have found this article interesting and learned at least few things from it. I believe most of these informations are not the easiest to find and it’s always good to know how your tools work, to understand their behavior. Source Engine 1 is old and its technologies might not be used anymore in the future, more powerful and credible technologies are released frequently but it’s always good to know your classics, right? 
I would like to thank Thrik and ’RZL for supporting me to write this article, and long live the Core!
// Written by Sylvain "Leplubodeslapin" Menguy
Additional commands for fun
Mat_luxels 1                              // Allows you to see the lightmaps grids Mat_fullbright 1                         // Disables all the lighting (= fullbright). On CS:GO, cascaded shadows stay and you should delete them as well (cf next command) Ent_fire env_cascade_light kill  // KILL WITH FIRE the cascade shadows entity Mat_drawgray 1                        // Replace all the textures with a monochrome grey texture, useful to work on your lighting  Mat_fullbright 2                         // Alternative to Mat_drawgray 1 Bonus:
Mat_showlowresimage 1           // Minecraft mode

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.
 
Lightmap baking
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:

Or...

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:

Another 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: 
https://www.desmos.com/calculator/1oboly7cl0
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

(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.
 
 
Helpful Playtesting
 
Every week for the length of the contest, eligible maps will be playtested during /r/GlobalOffensive community nights according to a sign-up schedule. Slots on this schedule will be filled on a first-come, first-serve basis following an approval process, but we will try our best to accommodate everyone at least once. However, because it’s impossible to guarantee that all contest entries will have the chance to be playtested, /r/GlobalOffensive playtesting is a supplemental, helpful tool which will have no bearing whatsoever on contest judging.
 
You can register for a playtesting slot here. Remember -- playtesting registration is first-come, first-serve!
 
 
Enter Your Level
 
To officially enter your level into this contest, post a WIP thread with a link to your level’s Steam Workshop page in Mapcore’s official event forum.
 
Posting a WIP thread with a link to your level’s Steam workshop page constitutes your official entry into the contest, however you don’t need to do both at the same time. In other words, you can post your WIP thread and then update it later with your workshop link if you’re not ready to go right away. You can also feel free to continue updating your workshop level after you’ve posted your workshop link – contest entries will not be judged until after the submission deadline.
 
 
The Deadline
 
 
Your level must be submitted to Mapcore by August 31st, 2015 at midnight Pacific Standard Time (PST).
 

Our panel of judges will then select four finalist levels based on the following criteria:
Fun factor Visual/thematic presentation (graphics) Overall polish
Grand Prize Deadline
After the top four maps have been announced, /r/GlobalOffensive users will put them to the test!
Once all four finalist maps have been tested, mappers will have two weeks to revise their work based on community feedback. After those two weeks, an official Grand Prize Winning Map will be chosen!
 
 
 
Contest Calendar
 
 
 
Our Goal
 
The goal of this event is to raise awareness about Mapcore's incredible level design community and the incredibly useful playtesting capabilities of /r/GlobalOffensive. Both Mapcore and /r/GlobalOffensive are free resources available to all mappers. To date, Mapcore users are responsible for creating more than 70% of Valve Operation levels. Mapcore’s staff are unpaid volunteers, and do not personally profit in any way from additional traffic to the site.

Prizes
 
Of course, it wouldn’t be a contest without a reward… In addition to the helpful feedback and free publicity that CS:GO mappers will receive by participating in this event, each finalist will also receive:
Eternal Bragging Rights™ and a showcase on Mapcore (where their level will be highly visible to industry-veteran game developers and the rest of the community) A monetary prize ($1000 + Mapcore swag for first place; $400 for second place; $200 for third place; $100 and Mapcore swag for fourth place) The top-finishing map will also be played in a competitive show-match casted and streamed by goRGNtv, for all to watch and enjoy! *NEW* CEVO has generously agreed to host the winning map in their PUG rotations for one month! *NEW* Added $1,000 to prize pool thanks to Gamebanana.com and EGO DEATH (gun skin creator) *NEW* Valve prizes!  
                   Top 4 will receive
1. Signed CS:GO poster
2. CS:GO Lanyard
3. CS:GO Vinyl Sticker
 
         First place will receive a CS:GO prize pack:
1. Signed CS:GO poster
2. CS:GO Lanyard
3. CS:GO Vinyl Sticker
4. CS:GO SteelSeries Kana Mouse
 
 
This is your big chance -- get to it!
Good luck, mappers!
 
Additional Rules
Remakes of older maps are NOT allowed. All works must be original to you and their layouts must not have appeared in any prior versions of Counter-Strike. Custom artwork is allowed and encouraged, but must meet workshop guidelines. Collaborations are allowed and encouraged. Any contest winnings arising from a collaboration will be split in accordance with the collaborators' mutual agreement.  
 
Judging Procedure
Mapcore staff will rate their top four maps of the contest, results will be tallied and all votes given equal weight. Some time later, the judges and guest judges will rate the top four finalist maps and results will be tallied, with all votes given equal weight. Guest judges will be asked to act as tie-breakers in the event of any ties in the voting.  
Mapcore Judges
Jason “General Vivi” Mojica -- Creator of "Rose Iron" Skin (Overkill Software)
Patrick "Puddy" Murphy -- Creator of CS_AGENCY (Overkill Software)
RZL (Independent) -- Creator of DE_RESORT
Shawn “FMPONE” Snelling (Independent)
Johnny “Sprony” van Spronsen (Journalist)
 
Guest Judges
Matt "Sadokist" Trivett -- @Sadokist
Jason “Moses” O’Toole -- @JmosesOT
Daniel "DDK" Kapadia -- @followddk
James Bardolph -- @jamesbardolph
Anders Blume -- @OnFireAnders
 
---
Our Thanks to 
EGO DEATH (Steam Workshop author)


 
 
 

Your objective We'd like you to re-imagine a scene of your choosing from any of the Half-Life games. To be clear, we're not looking for remakes of scenes — we want you to completely reinterpret a scene, approaching it from a fresh perspective. You can, however, use assets from Black Mesa.
Here are some examples of ideas you could develop:
The Tram ride at the beginning of Half-Life. What if somebody else pushed the cart? Gordon was late, so they got somebody else and the resonance cascade happens when Gordon is still on the tram. It crashed to the ground but leads him to a previously unseen section of Black Mesa. Black Mesa. What if Half-Life's infamous research facility were hidden underneath a city or town rather than out in the desert? Surface Tension. This particular event occurs on the side of a Citadel. Yes, it doesn't fit the story, but that's not important. This is about high cliffs and long falls. Opposing Force. What if Black Mesa were devastated by this game's nuclear bomb quite early on during the story, leaving Adrian Shepherd to navigate a version of the research facility resembling a post-apocalyptic nightmare? Point Insertion. Instead of arriving at a city train station, Gordon finds himself in a deserted and derelict village station, perhaps near enough to Ravenholm, to feel the threat. Being seen by Civil Protection may be the least of his worries. City 17. What if the Combine had chosen the United States, France, or London to be their primary city? The only limitation is your imagination, which we want to see run wild — create the most wonderful interpretation of Half-Life's universe that you can conceive. Whether your project is big or small, you should strive to create something that will delight Half-Life fans.
How to share your progress Because this is a joint challenge, there are two places for this:

Where you may discuss the challenge and share progress of your work, which we hope that you will! RunThinkShootLive challenge article
Where you can do the same. Both will be compiled together for judging and articles after the challenge ends, so you don't need to post in both places (although it's not a problem if you do).
 

Prizes Prizes are being donated by both MapCore and RunThinkShootLive, in addition to your work being immortalised in our archives for others to enjoy.
For the winner
A lightly used hardback copy of Valve's rare Half-Life 2 development book, Raising the Bar, kindly donated by Don aka Unq. This book is a must-read for any fan of the game, and particularly those interested in its development process. In addition to being a collectable in its own right, this particular edition is signed by Valve staff, arranged by a friend of Phillip's who works there.
For the almost-winner
Don't feel bad, you nearly made it. Have a plush companion cube plus a MapCore mug or t-shirt, and know that we love you.
...and for everyone else
All entries, except the winner and almost-winner, will be entered into a random draw to win Sniper Elite 3.
Challenge dates Begins: Thursday, 19th March, 2015 at 11am GMT
Ends: Tuesday, 28th April, 2015 at 11am GMT
Rules You can't have a challenge without rules, right? Here are the requirements:
Maximum one map per mapper per entry. The map must have at least one enemy and one weapon; i.e. playable. The map must be original and not have been released publicly before. The map must run in a system with only Half-Life 2: Episode 2 installed By entering the competition you grant RunThinkShootLive.Com and MapCore.org the right to release the map as part of the RaiseTheBarVille Mod. Maps must not appear for download before the release and for one month after the release of the mod. No assets from retail games other than Half-Life 2, Half-Life 2: Episode 1 or Half-Life 2: Episode 2 are allowed. Other assets are allowed with written permission from their original authors, which must be included in the entry. The organizers' decision is final and no correspondence will be entered into about it. The map must have a proper name. The map must have a proper filename: MapName_rtbv.bsp Each entry should be accompanied by a correctly formatted (vtf) background and chapter image. The name is not important, as it will have to be changed. All entries must be sent to: runthinkshootlive@gmail.com no later than the deadline. Frequently Asked Questions There have been a few questions asked about this challenge, so hopefully this will help you. However, if your question is not here and you have doubts, please don’t hesitate to ask, no matter how small your query.
Can I use assets from Black Mesa Source?
Yes, by all means, but you must pack them into your BSP. Yes, we know that may mean redundancy, but the map MUST run in a system that ONLY has Episode Two installed. We don’t want to force players to download BM.
Can an entry be a joint entry?
Yes, but there I still only one prize. You’ll have to fight to the death to decide who gets it.
Which games can I re-imagine?
Half-Life, Opposing Force, Blue Shift, Half-Life 2, Lost Coast, Episode One, or Episode Two.
Can I use assets from Lost Coast?
Yes, pack them into your BSP.
What about recreating a scene that was say… cut from one of the main games? Technically a re-imagining of a re-imagining.
No, but you could use the cut area as inspiration for something that was released in one of the games. What we don’t want people to do is remake a cut section from a game.
Can simply change a location?
Well, yes, but again, there should be some element of “What if…?” in the map. Simply changing a town for a city is only part of what we are looking for. You map should really be the result f some change, however minor, in the story.
How do you define a scene?
In the context of this challenge a “Scene” is a part of the game that has some effect on the following game. So, changing one location for another is not really enough. What we are looking for is something that takes the game in a different direction.
Can we submit mini-mods instead of a map?
Sorry, no. Your entry must be a self contained map.
Can I submit something artsy?
Sure, but it must have at least one enemy, one weapon and a player spawn.
Can we decompile or remake specific locations from Valve maps?
We think it’s best if we disallow this. Mainly to avoid any potential problems. Please start your map from something new. However, we will allow a very small section if this is just used to “fit into the story”. For example, in Episode One, at the beginning when Alyx and Gordon are thrown into the Citadel. If you map started at the bottom but then things went very differnt from the game, that would be okay.
How should I start my map?
We suggest a little text at the beginning to set the scene. Something like…”What if Gordon were late and somebody else push the cart? Let’s find out“. It’s not compulsory but it might help.
What’s the limit of changes we can make?
Wow, that’s a tough question. Your changes MUST NOT affect maps that may be after yours in the final mod.
My question is not here, what should I do?
Ask in the RTSL post or MapCore thread. Somebody will respond quickly.
Closing words We really hope that you have fun with this. MapCore has a very long history of facilitating development of levels for Half-Life and its mods, in fact we were founded around that very concept. As such, we're hopeful that the community still has that passion for one of gaming's finest classics, and is keen to apply modern-day skills and technologies to bringing Half-Life's universe to life — because Valve sure isn't doing it any time soon!

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!
 

By KNJ
 
Interview with Mateusz 'seir' Piaskiewicz, Techland Senior Level Artist
4,100+ reads
Interview with Rosin 'kikette' Geoffrey, Arkane Studios Environment Artist
6,700+ reads
Deus Ex: Human Revolution scene interview with KNJ
6,800+ reads
Virtual Reality: The Final Platform
5,300+ reads
Interview with Francois 'Furyo' Roughol, BioShock Infinite Level Designer
6,200+ reads
Interview with Thibault 'dkm' Courbet, Wolfenstein: The New Order Level Designer
6,600+ reads
Interview with Lenz 'penE' Monath, Environment and Lighting/VFX Artist
3,900+ reads
Interview with Thiago 'Minos' Klafke, Blizzard Environment Artist
7,600+ reads
Interview with Paul 'PaulH' Haynes, Homefront: The Revolution Senior Level Designer
5,000+ reads
Korath: The Witcher Saga scene interview? with Krzysztof 'Tepcio' Teper
3,700+ reads
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
By Min0s
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.
 
By Furyo
 
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.
 
By Kikette
 
SpronyvanJohnson's map given feedback in the form of an overpaint by Seir
 
By penE