Xanthi reacted to Puddy for an article, Dynamic levels - in Payday 2 and beyond
Payday 2 is a cooperative first person shooter where players band together to commit various crimes in the endless pursuit of wealth, infamy and cool masks to cover their criminal faces with. The game recently celebrated it’s third birthday, yet it still retains a steady player base. How then has the game kept players engaged throughout the years? The many and regular content updates are surely a big part of it. Another draw must be the fleshed out progression systems that offer tons of customization. I would argue that the lifeblood of the game is its dynamic level design; it is what keeps the game replayable and fun. In this article I will discuss what dynamic level design is and how it was used to build “Hoxton Breakout”, one of the game’s most popular missions.
Payday 2, Left 4 Dead 2 and even XCOM2 all use some form of dynamic level design.
What is dynamic level design?
Dynamic level design is all about creating levels that are as replayable as possible; it is about retaining the challenge and keeping players on their toes. This is achieved by introducing elements that change between playthroughs, things that make the level a bit different each time you play. Dynamic levels are still designed and built by hand, so to speak, which makes them different from procedural levels which are created from automated algorithms.
Dynamic levels are useful in games where the developer wants the levels to provide more gameplay than a single playthrough would. This approach has the added benefit of allowing different players to come together and enjoy the same level, irrespective of whether they have played it many times before or not at all. This can make dynamic level design ideal for co-op games and it can be essential for retaining players over longer periods of time, just like Payday 2 has done.
Building a dynamic level
The process of building a dynamic level certainly differs from more traditional single player level design. Instead of crafting a linear experience in meticulous detail, a designer must seek to create a broader structure of what will happen in the level and then design dynamic elements, things that change between playthroughs, within that structure. These dynamic elements need to be designed with care, so that the level actually changes in meaningful ways between playthroughs. The process of making a dynamic level will vary from game to game; it all depends on the game's mechanics, setting and other details. By sharing the design of a Payday 2 level I hope to illustrate what a dynamic level can look like and also showcase the overall possibilities of dynamic level design.
Hoxton in all his glory, featured here in this promotional art. Shortly after his breakout, he leads a daring break-in at the FBI to uncover who ratted him out.
In the Payday 2 mission “Hoxton Breakout” players are tasked with breaking their old heisting comrade Hoxton out of custody. During the breakout Hoxton shares his suspicion that his capture was caused by an unknown snitch. To uncover the truth, the PAYDAY gang set their sights on the headquarters of the Federal Bureau of Intervention (not to be confused with any real life organization...). This sets the stage for the mission’s second level and the one I will be discussing here.
In this level, the players will enter the FBI headquarters together with Hoxton (an NPC). They will fight their way to the “Operations Room”; the place where the FBI servers are kept and where the Payday gang is hoping to find the information which reveals the identity of the snitch. Hoxton will search through the servers and when he has found what they need, the gang will escape. No matter how many times you play the level, the overall structure will stay the same. Instead, it’s the dynamic elements within this structure that change and make it replayable. What are those, you ask? Let’s take a look!
Clockwise from top right: The FBI HQ lobby, a central area in the level. The FBI director hides behind his desk. Hoxton and the Payday gang enter the lobby.
The Operations Room
Players will spend a lot of time in the FBI Operations Room. Hoxton will be hard at work searching through the servers, leaving players to defend him from relentless police assaults. The combat space will change in a number of ways between playthroughs.
Entrances - Most of the entrances to the Operations room are selected dynamically in various combinations, which changes which choke points the player must defend.
Windows - The ‘Operations’ room is two floors in height and the second-floor windows overlooking the room are placed in different positions. Players must watch them for enemy fire.
Fuse box - The fuse box, which enemies use to cut the power to the servers and pause your progress, can be placed in a few different positions. Players must defend it.
Ceiling breaches - SWAT troops can breach the ceiling of the ‘Operations’ room and rappel down right into the thick of it! There are a few places where this can happen (it doesn't always).
These dynamic elements will vary and change independently. This can be very desirable, as it will give you a large set of different combinations and improve the replayability of the level. For example, even if the fuse box is in the same location in two separate playthroughs, the positioning of the entrances and windows will change how the players approach the situation, which will help reduce level fatigue.
The Operations Room. The Servers are kept in the room under the illuminated FBI logo.
There are four servers Hoxton must search through in the Operations Room. Between the searching of each server, Hoxton will need the player's assistance and send them on a “quest”. There are five different quests, though only three are selected and used in each playthrough. They can be selected in any order and combination. Each quest and its gameplay have been designed to have a slightly different flavor.
Security Office - The next server happens to be heavily encrypted. You need to break into the Security Office, download the encryption keys and get them back to Hoxton.
IT Department - The next server is missing and the log states it was taken to the IT Department for maintenance. You must locate the IT Department, find the missing server and bring it back to Hoxton.
Archives - Hoxton finds a reference to some physical files kept in the archives. You need to go down to the basement, search through the archives and bring the paper files to Hoxton.
Forensics - Hoxton learns that the FBI has evidence related to the traitor. Players need to break into the evidence locker, find the right piece of evidence and then scan it in the nearby laboratory for clues before returning to Hoxton.
Director’s Office - Hoxton encounters some files on the next server that can only be accessed by gaining direct approval from the FBI Director. You must head to the director’s office and use his computer to approve all of Hoxton’s security clearance requests.
What this means is that players won’t know exactly which “quests” they will tackle each time they play the mission, or in which order they will face them. As the difficulty slowly ramps up during the mission and the players’ supplies generally are lower towards the end, completing the same quest as either your first or last one can become quite a different experience, even though the quest itself doesn’t change that much. Allowing the quests to be arranged in any order and combination simply gives the mission a slightly different flow each time.
The five quests, clockwise from top right: IT Department, Security Office, Archives, Forensics. Center: Director's Office
The Combat Now, it’s about time we talked about the combat. It is essential for the replayability of a level that the combat isn’t static and that encounters vary between playthroughs. To solve this, Payday 2 has a spawning system that serves up dynamic enemy encounters. The system unburdens individual level designers and creates a consistent and tweakable way for the game to spawn enemies in all levels. For those of you who have played the Left 4 Dead games this may sound very familiar. The system isn’t completely automated and the level designer can control a few variables.
Difficulty - The player selects the overall difficulty of a level before starting, but a designer can tweak the difficulty to a factor between 0 and 1. This can be adjusted at any point during the mission and can be tied to certain events.
Spawn locations - A designer designates spawn locations manually. The designer can toggle spawn locations on and off, change how often they can be used to spawn enemies and which kind of enemies are allowed to spawn from them.
Enemy Wave Mode - Police assaults occur regularly and this is generally handled by the system, but a designer can force a police assault or a complete break from them.
Snipers/Harassers - The placement of snipers and so called harassers, regular SWAT troops who harass players from vantage points, is done manually. It is up to the designer to place them in challenging, but fair, positions and script logic which decides when and if they appear.
What this all means is that while the spawning system does the heavy lifting and creates varied combat encounters, a designer can fine-tune the experience and still direct the combat somewhat. For example, in Hoxton Breakout the difficulty is slowly ramped up after each completed server, the spawn locations are continuously tweaked throughout the mission to make fights fair and when it is time to escape an endless police assault is forcefully triggered to increase the stakes!
A dynamically spawned enemy squad moves towards the Payday gang.
The keycard economy
In Payday 2, keycards are single-use items that are occasionally used to open certain doors. In order to add depth and strategy to the level, I added something to this level which I like to call “the keycard economy”. In every playthrough, players can find 3-4 keycards which can be used, i.e. “spent”, on a variety of options like overriding doors to seal them off from enemies, unlocking rooms that contain precious resources or opening doors that lead to objectives. The value of the different options can change between playthroughs, depending on dynamic variables and which loadouts the players have. Since players can’t have all the options, they must choose wisely. This allows players to refine their strategy over the course of multiple playthroughs, adding to the level’s replayability.
The little things We’ve discussed all the major dynamic elements of the level at this point, but it is worth mentioning that replayability also arises from smaller dynamic elements too. These smaller surprises can throw players off and force them to adapt accordingly. A good example can be found in the Security Office, where the police sometimes pumps in tear gas when players are trying to complete the objective inside. This forces players to leave the relative safety of the room and charge head first into the police forces which are surely waiting outside. Part of making a dynamic level should be to identify and implement these little game changers!
Clockwise from top right: The Security Room fills with gas. A keycard has been used to seal a security door. An innocent keycard. A SWAT team rushing to thwart the payday gang.
To summarize, the level we’ve looked at is about defending a location and completing short “quests”, with both activities changing in different ways between playthroughs. In addition to this variety, enemies are dynamically spawned, occasional surprises appear and players are able to learn and master the keycard economy over the course of multiple playthroughs. These dynamic elements, this variety between playthroughs, is what turns the level into a dynamic one.
This level was made for Payday 2 and, as mentioned, dynamic levels will look a bit different depending on the game and its needs. The Left 4 Dead games have less emphasis on objectives and focus more on linear progression through a level, with dynamic enemies, items and minor path changes along the way. The Killing Floor games have arena levels that suit the game’s wave-based horde mode and these levels feature fairly simple dynamic elements: enemy and item spawning as well as the location of the weapon and item shop. The revived XCOM franchise uses levels which have designated areas or “slots” where different buildings and structures can fit in and shift the layout accordingly. The XCOM games also allow different missions to be played on the same level, enabling levels to provide even more gameplay mileage.
The dynamic level design approach may fit these games, and others like them, but it is not suitable for all kinds of games and it definitely comes at a price. Since dynamic levels are designed to be replayable, heavily scripted story moments and set pieces may have to be deemphasized or removed outright. Playing through such sections may be thrilling once or twice, but they generally lose their appeal very quickly. Furthermore, some degree of polish is generally lost in the process of making dynamic levels. The fact that you are making an experience that can’t just happen “in one way” means you can’t necessarily polish, and control, every moment of gameplay to an insane standard, like you would expect in an Uncharted game for example. Additionally, an incredibly strong core gameplay loop is almost a requirement for a game with dynamic level design. Since the levels can’t be overly scripted, directed and set-piece heavy, the levels can’t compensate and “lift up” a slightly weaker core gameplay. Finally, one must also consider that creating dynamic elements in a level takes time, time which could be spent polishing or making more non-dynamic levels.
These drawbacks must be weighed against the potential benefits. After all, the value of replayability should not be underestimated. As I mentioned in the beginning of the article, dynamic levels seem to be almost ideal for co-op games. Playing games together definitely adds something to the experience and this can help to compensate for some of the potential drawbacks like the lack of set-pieces. Adversarial multiplayer games, i.e. player vs player, don’t necessarily stand much to gain with the dynamic level design approach as the element of human unpredictability and challenge is usually enough to keep players engaged and entertained. By looking at XCOM, we can see that dynamic levels can be used to great effect in a game that isn't a shooter nor a cooperative one. And if we compare them to procedural levels, dynamic levels requires less sophisticated technology to create, but more human labor, and can offer something that feels a bit more handcrafted and unique. Ultimately, game makers need to look at the dynamic level design approach, its pros and cons, and ask themselves: is it the right approach for us?
Xanthi reacted to Alf-Life for an article, Creative Airlocking: streaming in action games
Creative Airlocking: streaming in action games
This article will discuss the loading and unloading of areas in linear single-player action titles, and look at contemporary examples of how the best games mask these so they appear seamless.
When designing levels, Level Designers and Environment Artists must consider that their assets all have to fit within memory at once. While older action games like Wolfenstein 3-D and Doom would load the entire level with a Loading Screen at the start of each map, games like Half-Life started a trend of loading smaller sections gradually so they could squeeze in more detail and also provide a more seamless experience for players, making the game feel like one long adventure.
At the time, going from one space to the next in Half-Life resulted in a seconds-long hitch with the word “Loading” on screen. There was no warning that it was going to happen, although Valve’s Level Designers oftenplaced these level transitions in smart places; usually down-time between combat and in a natural chokepoint. In later years, with faster computers, these load times decreased and are now almost seamless.
Half-Life displays a small loading message when transitioning between levels.
Currently, blockbuster series like Gears of War and Uncharted provide truly seamless transitions. After one long initial load for a new chapter with a completely new location (with new art) – sometimes masked behind a pre-rendered movie – “buffer” Streaming Sections are used, in which the previous area is unloaded, and the next loaded, on the fly. Since a lot of the globally-used entities are already loaded, and the environment is usually the same, assets can be shared, which can reduce these transition load times to much less than the initial level load.
Essentially, these games take the smaller loading bar/screen of a more continuously-laid-out game like Half-Life, Portal 2 or Fallout 4 and make the player spend that time in the game world. If done creatively, players won’t even notice it. They might even enjoy the down-time if it’s well-paced, like The Last of Us where it can be spent on a thought-provoking puzzle or with the characters discussing something interesting.
Most action games budget out large areas, and then connect those with these smaller Streaming Sections.
Section (A) is a huge space with lots of combat, Section (C) is another. Players in Streaming Section (B) can’t see into both (A) and (C) at once. Section (B) is where Section (A) is dropped from memory and (C) starts to load in. Section (A) being dropped shouldn’t happen in view of the player, and unless the game supports backtracking it is wise to place a back-gate to stop players returning, for maximum efficiency. As soon as Section (A) has been dropped, Section (C) can start loading in. It must have been loaded by the time the player exits Section (B), so it is also wise to front-gate players in case they rush through.
The best way to think of a Streaming Section is as an airlock; the “door” behind the player is locked, the next area is loaded, and the “door” ahead opens. Ideally, these sections aren’t literal airlocks but instead nicely-disguised puzzles or narrative spaces between the action.
Back-gating, and Unloading
Back-gating, as the term suggests, is when the player is prevented from returning to a previous area. The ‘gate’ behind them is closed, in a lot of cases locked. This doesn’t have to be a literal gate or door, though. A ceiling can collapse causing debris to block the path behind the player, the player can fall through the floor and not be able to climb back up, they can pass through a one-way portal and not get back.
Back-gating after entering the Streaming Section is usually done around a corner where the player can’t see Section (A) being unloaded.
One-way animations are the main manifestation of these in modern action titles. Think of how many doorways your player character has held open, only to have it collapse behind them. The level section behind that door is now being unloaded, to make space in memory for the next large section. In co-op games, these animated interactions are a great way to bring players back together so that Player 2 isn’t left behind, only to fall through the world, in the section that is just about to be unloaded!
The Last of Us has a huge variety of bespoke, painstakingly-animated back-gates.
A cut-scene can also serve as a good back-gate, as long as it makes sense in the context and/or story so as to not feel tacked on, and is within development budget!
One-way drop-downs are also a great and less flow-breaking back-gate. If the L-shaped area just before the drop-down can be kept in memory, as soon as the player drops down a ledge they can never climb back up, the previous area can be unloaded. The only down-sides to this softer back-gate are that they can feel contrived unless the game’s art and world can support it (terrain and collapsed structures are great for this), and that co-op players may have to be teleported to the dropping player so that they don’t fall through the world when Section (A) is unloaded.
Slowing the player down, and Loading
As Streaming Sections are usually connectors between two larger areas, they naturally make for slower-paced breaks in the action. Since Section (C) is being loaded in, slowing the player down in (B) – either literally as with Gears of War’s infamous forced walks or cerebrally with light puzzle gameplay – can be more efficient and interesting than just making a large footprint which has to cater for a player, say, sprinting for 30 seconds.
Even when rushed, this plank puzzle in The Last of Us takes time and offers a nice respite.
“Popcorn” encounters with just 1-2 enemies can be a good trick to allow loading to finish and slow players down and prevent them from simply rushing through a short Streaming Section. They also keep players on their toes and vary the flow from, for example, combat to puzzle to combat.
Interactive Objects such as the slow-turning valves in Killzone 2 and the Gears of War games can also buy some loading time, as can environmental obstacles such as jumps or mantles or animations where the player’s buddy looks around for, and then finds, a ladder to kick down for the player to climb (also a good front-gate).
Interactions like the valve in Gears of War slows players down and can also act as a front-gate.
These approaches can also be combined in ways that fit the feel of the game, such as a Grub locking the player in a room and flooding it with frightening enemies in the first Gears of War game.
Batman Arkham Asylum does a great job with additional ‘softer’ methods of slowing players down by playing a captivating well-acted taunt on a monitor from The Joker, or by encouraging exploration with The Riddler’s location-specific riddles or any number of collectibles.
Front-gating, and Loaded
As with Back-gates, front-gates are quite self-explanatory – the exit to the area the player is currently in is locked until certain conditions, such as all the enemies in the room being dead or the next area having loaded in, are met. Again, this doesn’t have to be a literal gate or door, just an obstacle in the world that can change its state from closed and locked to open.
A lot of games from the Call of Duty series to Killzone 2 to The Last of Us extensively use friendly characters to unblock a front-gate; chain-link fences are cut through, doors are kicked open, wooden beams are lifted. New waves of enemies can also open a front-gate for the player and offer the bonus in that noisy, gun-firing AI attract players, like carrots on a stick, to the newly-opened exit. Many action games have excellent examples of enemies blow-torching open a door to get in or a huge monster bursting in through a wall; not only are these cool enemy entrances, but oftentimes their new unorthodox entrance-ways become cool exits, sign-posted by their un-gating event.
Previously-locked doors in Halo often flash and make noise when opened by new enemies.
Not all games front-gate the exits of their Streaming Sections because the time needed to load a Section (C) can usually be accurately gauged, and the acceptable fallback is a slight hitch. However, front-gates do provide that extra failsafe to ensure the next area is loaded before leaving a Streaming Section – in this case, a player with a scratched disk or corrupted file could see out of the world, at best, or get stuck or fall out of the world, at worst (though it could be argued someone with a scratch or corrupted files might see worse issues regardless).
The biggest issue here is that front-gates need to fit the game or the level art – neat doorways or bottlenecks aren’t always possible. The other big issue is repetition; if a specific door interaction animation is always used, the game needs to provide a lot of variety in that animation!
One trick that can be used to alleviate repetition, however, is if the front-gate is out of sight near the end of the Streaming Section (A). A check can be done to see if Section (C) has loaded, and if it has, the door can potentially be pre-opened saving the player another potentially-repetitive interaction but also holding as a true front-gate if a player does rush through.
Batman Arkham Asylum had an interesting front-gate in the penitentiary sections; a security camera scanned Batman once before opening the door. Given the backtracking-heavy structure of the game, when racing through at full pelt, if the next area had not finished loading, the camera would loop the camera’s scanning animation. This is a great compromise because the camera scan completely fits the fiction of the world, and an extra scan animation would probably go unnoticed by many players.
Batman Arkham Asylum’s Penitentiary’s doors only open when loading is complete.
In most linear action games, keeping the player immersed in the world is preferable to seeing a loading screen. If developers can create interesting activities, take advantage of slower pacing through narrative, or just make smart use of assets and an interesting space to traverse, Streaming Sections can be part of the world and not feel like generic winding corridors that stand out even to uninitiated players as padding.
Copyright © Martin 'Alf-Life' Badowsky 2016
Xanthi 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
Xanthi 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!
Xanthi reacted to Thrik for an article, Announcing the winners of our RaiseTheBarVille Half-Life mapping challenge
Levels Nova Exchange
By Erik-Silver Toomere (ESToomere)
“After taking a wrong turn on the way to Lighthouse Point… Gordon stumbles on a Combine secret”. Takes place between the chapters Sandtraps and Entanglement, replacing Nova Prospekt.
By Justin Carlto (SneakySpeckMan)
The strider at the end of Half Life 2 Episode 1 destroys the escape train, leaving Gordon and Alyx stuck in City 17 as the Citadel goes critical.
By Dan Jordan (The_Rabbit42)
A re-imagining of the classic scene from Half-Life.
Mod Details Title: RaiseTheBarVille
File Name: hl2-ep2-sp-mc-raisethebarville.7z
Author(s): Erik-Silver Toomere aka ESToomere, Justin Carlton aka SneakySpeckMan & Dan Jordan aka The_Rabbit42
Date Released: 09 May 2015
MapTap Users Download directly into MapTap [47.10MB]
You must have MapTap installed before using this link.
Direct Download Download to your HDD [47.10MB]
You can still use it with MapTap once you have downloaded it.
Manual Installation Instructions 1. Copy the RaiseTheBarVille folder into your …SteamSteamAppscommonsourcemods folder.2. Restart or start Steam.
3. RaiseTheBarVille should now be listed in your Library tab.
4. If you require more help, please visit RunThinkShootLive's Technical Help page.
Judges There were 3 judges for this challenge: Phillip (RunThinkShootLive), Ryan 'Thrik' Williams (MapCore), and Don aka Unq (who very kindly supplied the RaiseTheBarVille first Prize).
Winners Winner: Blast Pit
All judges felt this was the perfect combination of using the theme in a clever way and making a map that was fun to play.
Almost-Winner: Nova Exchange
This was a very detailed and thoughtful entry that all the judges enjoyed playing but felt it lacked player guidance too often.
Third Place: Delayed
While short and light on compelling gameplay, it delivers exciting set-pieces and great visuals.
The judges' more detailed reviews can be found in the comments of this article and/or RunThinkShootLive's equivalent article. Feel free to leave your own — in fact, please do!
Prizes 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. As this was one person in the end, this has now become the third-place prize.
Screenshots A selection of 3840x2160 screenshots is available on Dropbox. They haven't been included directly in this article because they potentially spoil set-pieces within the levels.
Video The playthrough/walkthrough below is provided by PlanetPhillip. See more of his playthroughs at VP: PlanetPhillip.
Steam Grid View Images Three grid view icons are included in this file. To use the included grid view icon, select “Gridview” in Steam (top right corner). Right click on “RaiseTheBarVille” and select “Set Custom Image”. Then browse to the SourceMods folder and then to RaiseTheBarVille/steam-gridview-icons folder and select the image you prefer. Then click “Set Image” and that’s it. Of course, you can create your own custom image if you prefer.
Other Bits and Pieces There are a few additional things that you might want to check out over in the RunThinkLiveShoot equivalent of this article, such as a poll that lets you vote for your favourite, additional screenshots, and download statistics.
Xanthi reacted to Sentura for an article, Exploring Unreal Engine 4 Scripting: Part One
On the other hand, UE4 has also been somewhat stripped of “default” content in order to emphasize the user-generated content located on Epic’s new marketplace. This tutorial series is designed to bring you up to speed on UE4 level-design by showing you how blueprints work and how you can create your very own blueprint building-blocks.
Understanding Blueprints The Blueprint system is a visual scripting language central to all game interaction in UE4.
Blueprints come in two flavors: Level blueprints and Class blueprints. Level blueprints are attached to your level, whereas Class blueprints are self-contained templates for a single type of object in your level (a “class”) only. Anything you do in a Level blueprint can also be done in a Class blueprint, but Level blueprints additionally enable you to set up communication between multiple Class blueprints.
Let’s take a look at what actually goes on inside these blueprints.
Inside Blueprints Let’s start with the two basic blueprint nodes: Functions and Variables. Variables can be explained as containers of object data, while functions essentially perform game logic upon variables.
The next section will cover these nodes in more detail.
A Player variable with a Jump function. As illustrated, executing the function (f) causes the player to jump
Object Data (Actors and Variables)
Although they are very versatile, variables are most commonly used to control actors, objects that exist inside the game world. Characters, weapons, doors, switches are all examples of actors. Additionally, every actor’s variables can potentially be manipulated by functions, for example the health of a character stored as an integer value.
A actor variable (player) with health and position stored as an integer variable (green) and a 3D-vector variable (yellow), respectively
Actors can also contain components: other actors incorporated inside the main actor. This enables static meshes to have component collision boxes, or to be paired with component particle effects, among other things.
The components of this door object are two meshes (a door and a doorframe) and a collision box that helps control the door’s physics behavior
Functions are nodes of logic which can be executed (called) to perform a certain task. If something needs to take place in-game, such as a player picking up a weapon, functions can enable as well as add additional consequences to that action.
A function execution string (the white line)
Functions present and modify variable information. For example, a function which acts upon information gathered by a variable could teleport players to specific game-world coordinates. A ‘getter’ or ‘pure’ function, on the other hand, merely relays information for use elsewhere, such as reporting a player’s current coordinates in the game world.
A ‘pure’ function (green). Notice that ‘pure’ functions do not have independent execution, only when linked with a regular function (blue) does this particular function have effect
So, we’ve covered Variables and Functions. But how does the Blueprint system know how and when to react to incidents inside the game world?
Events allow different actors to communicate with each other. For instance, an event controls when an actor collides with another actor, or what an actor should do if a collision actually occurs. More examples of an event are a door opening as a character nears it, a switch being thrown, or a barrel exploding after it has taken sufficient damage. An example of an event could even be as fundamental as a player using controls to move their character model. Customized events can be called much in the same way a function would be.
Event (red) called if an actor is hit. The event triggers a function linked to taking damage. This example is intended for learning purposes, not for practical use
Quick aside: In general, as a good practice, variables, functions and events should be named for their exact purpose. This helps both you and others read what’s going on in your blueprints. An actor named “player”, or an integer named “health” is easier to understand than one named “asdhjkashdj”!
For more information on variables, functions and events, please refer to Epic Games’ own documentation, which provides encyclopedic knowledge about the topic.
Case study Now that we understand the building blocks of UE4’s Blueprint system, let’s look at a practical example: the Class blueprint of a sliding door (If you want to create your own sliding door, I recommend taking a close look at Epic’s in-depth guide.
When a player gets close to it, the door opens. When a player leaves the door’s vicinity, it closes. Let’s examine the door’s blueprinting:
You can see that the door actor is composed of several components: a frame object, a door object and a triggering box
In this image, we can clearly see the nodes used to trigger the door’s opening and closing. For example, the event OnComponentBeginOverlap triggers once a player steps into the Box component actor listed. That triggered event starts executing anything along the execution logic path, such as the Timeline function and the Set Relative Location function.
The Timeline function changes an integer with decimals - the Driver float variable – between 0.0 and 1.0 over time, and sends execution updates every time the float changes. The float variable is called Driver in this case, because it drives the door to either open or close. The Lerp function’s Alpha parameter then uses this float value to determine the exact position of the door between being open (float value of 1.0) and closed (float value of 0.0). The Vector variables Door Closed Position and Door Open Position are end points for Alpha to blend between. This is to ensure that the door opens and closes smoothly over time rather than instantly.
Set Relative Location then executes the data received from the Lerp at intervals put forward by the Timeline’s update execution for the door that we use. The result is a door which slides opens when players are nearby.
Lastly, our OnEndComponentOverlap event triggers the closing of the door by reversing its operation when players leave the triggering box.
Here you can see our moving door in action:
To be fair, this case study is a bit over-simplified in order to provide an example that can be easily understood. The real version of this door (which will be shown in the next part of this series) is a bit more advanced, but its core principles are exactly the same.
So far, we’ve covered the structure of variables, functions, events, as well as a common gameplay element like a sliding door. In the part two of this tutorial series, we’ll learn some more advanced blueprint features, such as class recognition, level blueprints and blueprint communication.
Thanks for reading!