Sigma reacted to FrieChamp for an article, Finding your own path as a professional Level Designer
The following article contains quotes from interviews with Todd Papy, Design Director at Cloud Imperium Games, Geoffrey Smith, Lead Game Designer at Respawn Entertainment, Paul Haynes, Lead Level Designer at Deep Silver Dambuster Studios and Sten Huebler, Senior Level Designer at The Coalition. A big heartfelt 'thank you' goes out to these guys who took the time out of their busy schedules to answer my questions!
On the MapCore.org forums many amateur level designers ask for feedback on their portfolios or for advice on how to break into the games industry. But once you have signed your first contract and you have your foot in the door you will realize that this step marks merely the beginning of your journey. It is a winding path with many diverging branches and without much information available on the road ahead. This is the reason why I decided to interview professional designers in Senior, Lead or Director positions to share their personal experiences and advice with others trying to navigate this field. It is worth mentioning that the questions were not selected and phrased with the goal in mind to compile a ‘how to get promoted fast’ guide. Instead I wanted to give level designers insights into the careers of others - who have stood at the same crossroads before - in hopes that they get the information to pick the path that is right for them.
Hands-On VS Management
At the beginning of his career, Todd Papy started out as a “designer/environment artist” – a job title that dates back to times when team sizes were much smaller and one person could wear both hats at the same time. As the project complexity and team size grew, he specialized in level design at SONY Santa Monica and worked on the God of War titles. During his time there he moved up the ranks to Lead Level Designer, Design Director and eventually Game Director. From level design to directing a game - a career thanks to careful long-term planning and preparation? “It wasn’t even on my radar” says Todd. “I just wanted to build a game with the team and soak up as much information from the people around me as possible.”
So how do level designers feel who step into positions where the majority of their daily work suddenly consists of managing people and processes? Do they regret not doing enough hands-on-work anymore? Todd says he misses building and crafting something with his hands, but instead of going back to his roots, he decided to look at the issue from a fresh perspective: “As a Lead or Director, your personal daily and weekly satisfaction changes from pride in what you accomplished to pride in what the team has accomplished.“ Today Todd is designing the universe of 'Star Citizen' as Design Director at Cloud Imperium Games.
Geoffrey Smith - who created some of the most popular multiplayer maps in the Call of Duty and Titanfall series and who is now Lead of the ‘Multiplayer Geometry’ team at Respawn Entertainment - says his output of levels remains unchanged thus far, but he can “easily see how being so tied up with managing would cut into someone's hands-on work”. Geoffrey calls for companies to provide the necessary training to employees new to management positions: “Managing people and projects is hard work and is normally a vastly different skill set than most of us in games have. Maybe that is why our industry has such problems with meeting deadlines and shipping bug-free games. A lot of guys work for a long time in their respective disciplines and after many years they get moved into a lead position. They certainly know their craft well enough to teach new guys but managing those guys and scheduling would be something brand new to them. Companies need to understand this and get them the training they need to be successful.” At Respawn Entertainment, the studio provides its department leads with training seminars, which helps the staff immensely, according to Geoffrey.
Sten Huebler, currently working as a Senior Level Designer at Microsoft-owned The Coalition, in Vancouver, says he definitely missed the hands-on work when he worked in a Lead capacity on 'Crysis' and 'Crysis 2': “I was longing for a more direct creative outlet again. That is why coming to The Coalition and working on Gears of War 4, I really wanted to be hands on again.” To Sten it was the right move because he enjoyed working directly on many of the levels in the game’s campaign and could then experience his fruit of labour with others close to him: "After Gears 4 shipped, playing through the campaign, through my levels with my brother in co-op was a blast and a highlight of my career. He actually still lives in Germany. Being able to reconnect with him, on the other side of globe, playing a game together I worked on...So cool!"
'Gears of War 4' developed by The Coaliation and published by Microsoft Studios
Paul Haynes, Lead Level Designer at Deep Silver Dambuster Studios, encourages designers to negotiate the amount of organizational tasks and hands-on work before being promoted into a position that makes you unhappy: “I always told myself that I wouldn’t take a Lead position unless it could be agreed that I retain some hands-on, creative responsibility, after all that’s where I consider my strongest attributes to lie. I agreed to both Lead positions (Cinematic/Level Design) under that principle - I never understood the concept of promoting someone who is good at a certain thing into a position where they potentially don’t get to do that thing anymore, as they spend all their time organising others to do it. So far I’ve managed to maintain that creativity to some degree, though I would imagine it’s never going to be quite the same as it used to be, as I do have a team to manage now. On the flip side though, being able to control and co-ordinate the level design vision for a project and having a team to support in fulfilling that is quite an exciting new experience for me, so not all the organisation and planning is unenjoyable.”
Specialization VS Broadening Skillsets
For the level designers who aren’t afraid of management-related tasks and who are willing to give up hands-on work for bigger creative control, what would the interviewees recommend: specialize and strengthen abilities as an expert in level design further or broaden one’s skillset (e.g. getting into system design, writing etc.)? Paul believes it doesn’t necessarily have to be one or the other: “I think it’s possible to do both (strengthening abilities and broadening skillsets) simultaneously, it would really depend on the individual involved. I would say that a good approach would be to start with the specialisation in your chosen field and then once you feel more comfortable with your day to day work under that specialisation, take on work that utilises different skillsets and experiment to see if you find anything else you enjoy.” He started out as a pure level designer but subsequently held roles that involved game and cinematic design at Codemasters, Crytek and Dambuster Studios. “I’ll always consider myself a level designer at heart”, says Paul, “though it’s been incredibly beneficial for me to gain an understanding of multiple other disciplines, as not only has it widened my personal skillset but it has enabled me to understand what those disciplines have to consider during their day to day job roles, and it has helped me to strengthen the bond with those departments and my level design department as a result.” This advice is echoed by Todd who encourages level designers to learn about the different disciplines as “that knowledge will help solve issues that arise when creating a level.”
'Homefront: The Revolution' developed by Dambuster Studios and published by Deep Silver
Sten also gained experience in related disciplines but ultimately decided to return to his passion and do level design. He explains: “It’s a good question and I feel I have been wondering about this myself regularly in my career. I think those priorities might change depending on your current situation, your age, your family situation, but also depending on the experience you gain in your particular field. (…) In my career, I was fortunate enough to try out different positions. For example, I was a Level Designer on Far Cry (PC), Lead Level Designer on Crysis 1 and Lead Game Designer on Crysis 2. Each position had different requirements and responsibilities. As a Lead Level Designer I was more exposed to the overall campaign planning and narrative for it, while on Crysis 2 I was more involved in the system design. However, my true passion is really on the level design side. I love creating places and spaces, taking the player on a cool adventure in a setting I am crafting. My skills and talents also seem to be best aligned on the level design side. I love the combination of art, design, scripting and storytelling that all come together when making levels for 1st or 3rd person games.”
Picking The Right Studio
As you can certainly tell by now, all of the interviewees have already made stops at different studios throughout their career. So each one of them has been in the situation of contemplating whether to pass on an offer or put down their signature on the dotted line. This brings up the question what makes them choose one development studio over the other? To Geoffrey it depends on what stage of your career you are in. “If you're trying to just get into the industry for the first time, then cast your net wide and apply to a lot of places. However, ideally, someone should pick a studio that makes the types of games they love to play. Being happy and motivated to work every day is a powerful thing.”
This is a sentiment that is shared by all interviewees: the project and team are important aspects, but as they have advanced in their career other external factors have come into play: “It’s not just about me anymore, so the location, the city we are going to live in are equally important.” Sten says.
Paul is also cautious of moving across the globe for a new gig. “The type of games that the company produces and the potential quality of them is obviously quite important – as is the team that I’d be working with and their pedigree. More and more over the years though it’s become equally important to me to find that balance between work and life outside of it. Working on games and translating your hobby into a career is awesome, but it’s all for nothing if you can’t live the life you want around it.”
And it is not just about enjoying your leisure time with family and friends, but it will also reflect in your work according to Todd: “If my family is happy and enjoys where we live, it makes it a lot easier for me to concentrate on work.” He also makes another important point to consider if you are inclined to join a different studio solely based on the current project they are working on: “The culture of the studio is extremely important. I consider how the team and management work together, the vibe when walking around the studio, and the desk where I will sit. Projects will come and go, but the culture of the studio will be something that you deal with every day.”
'Star Citizen' developed and published by Cloud Imperium Games; screenshot by Petri Levälahti
But it goes the other way around, too: When it comes to staffing up a team of level designers, these are the things that Todd looks for in a candidate: “First and foremost, I look for level designers that can take a level through all of the different stages of development: idea generation, 2D layouts, 3D layouts, idea prototyping, scripting, tuning, and final hardening of the level. People that can think quickly about different ideas and their possible positive and negative impacts. They shouldn’t get too married to one idea, but if they feel strongly enough about that specific idea they will fight for it. People that approach problems differently than I do. I want people that think differently to help round out possible weaknesses that the team might have. People who will look for the simplest and clearest solution vs. trying to always add more and more complexity.“
For lead positions, it goes to show yet again how important a designer's professional network is, as Todd for example only considers people that he already knows: “I try to promote designers to leads who are already on the team and have proven themselves. When I am building a new team, I hire people who I have had a personal working relationship before. Hiring people I have never worked with for such positions is simply too risky.”
Ups & Downs
While the career paths of the designers I interviewed seem pretty straightforward in retrospect, it is important to note that their journeys had their ups and downs as well. For instance Geoffrey recalls a very nerve-wracking time during his career when he decided to leave Infinity Ward: “We had worked so hard to make Call of Duty a household name but every day more and more of our friends were leaving. At a certain point it just wasn't the same company because the bulk of the people had left. The choice to leave or stay was even giving me heart palpitations. (…) After I left Infinity Ward, I started working at Respawn Entertainment and by work I mean - sitting in a big circle of chairs with not a stick of other furniture in the office - trying to figure out what to do as a company.” But he also remembers many joyful memories throughout his career: Little things like opening up the map file of multiplayer classic ‘mp_carentan’ for the first time or strangers on the street expressing their love in a game he had worked on. To him, shipping a game is a very joyful experience by itself and the recently released Titanfall 2 takes a special place for him. “The first Titanfall was a great game but we had so many issues going on behind the scenes it felt like we weren't able to make the best game we were capable of. (…) After all the trials and tribulations of starting a new game company, Titanfall 2 is a game I am very proud to have worked on.”
'Titanfall 2' developed by Respawn Entertainment and published by Electronic Arts
As a response to the question of what some of the bigger surprises (good or bad) in his career have been thus far, Paul talks about the unexpected benefits of walking through fire during a project’s development and the lessons he learnt from that: “It surprised me how positively I ended up viewing the outcome of the last project I worked on (Homefront: The Revolution). I’d always thought I would aim to work on big, successful titles only, but I guess you don’t really know what’s going to be a success until it’s released. Obviously it was a disappointing process to be part of, and a lot of hard work and effort went into making it, despite the team always knowing that there were some deep lying flaws in the game that weren’t going to be ironed out. We managed to ride the storm of the Crytek financial issues in 2014, coming out on the other side with a mostly new team in place and yet we carried on regardless and managed to actually ship something at the end of it, which is an achievement in itself. I see the positives in the experience as being the lessons I learnt about what can go wrong in games production which stands me in good stead should I decide to take a more authoritative role somewhere down the line. Sometimes the best way to learn is through failure, and I don’t believe I’d be as well rounded as a developer without having experienced what I did on that project.”
Last Words Of Advice
At the end I asked the veterans if they had any pieces of advice they would like to share with less experienced designers. To finish this article I will quote these in unabbreviated form below:
Geoffrey: “I guess the biggest thing for guys coming from community mapping is figuring out if you want to be an Environment Artist or a Geo-based Designer and if you want to work on Single-Player or Multiplayer. Each has its own skills to learn. I think a lot of guys get into mapping for the visual side of things but some companies have the environment artists handle the bulk of that work. So figuring out if making the level look great is more enjoyable to you or thinking it up and laying it out is, will help determine which career you should follow. Other than that, just work hard and always look to improve!”
Todd: “BUILD, BUILD, BUILD. Have people play it, find out what they liked about it and what they didn’t. Build up a thick skin; people will not always like your ideas or levels. Try out new ideas constantly. What you think looks good on paper doesn’t always translate to 3D. Analyse other games, movies, books, art, etc. Discover what makes an idea or piece of art appeal to you and how you can use that in your craft.”
Paul: “The games industry is not your regular nine to five job, and everyone is different so it’s difficult to lay down precise markers for success. Different specialisations have different requirements and you can find your choices leading to different routes than your fellow team members. You need to make sure you carve your own path and try everything you can to achieve whatever your personal goals are within the role; success will come naturally as a result of that. You need to be honest with yourself and others, open to criticism and willing to accept change. I’ve seen potential in people over the years hindered by stubbornness, succeeding in the games industry is all about learning and constantly adapting. Also it’s important to keep seeing your work as an extension of a hobby, rather than a job. The moment it starts to feel like a means to an end, you need to change things up to get that passion back.”
Sten: “I always feel people should follow their passion. I firmly believe that people will always be the best, the most successful at something they love. Of course, it is a job and it pays your bills, but it’s also going to be something you are going to do for gazillions hours in your life, so better pick something you like doing.”
Written by Friedrich Bode for mapcore.org
What are your personal experiences? Do you agree with the statements made by the interviewees? Any advice you would like to share with fellow level designers or game developers in general? Let us know in the comments!
Sigma 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
Sigma 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!
Sigma 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
Sigma reacted to Thrik for an article, Announcing the UE4 Whitebox Challenge winner!
DM-Helium by Chris '2d-chris' Kay
Congratulations! While no prizes were planned, Chris will receive a special winner's T-shirt for his efforts. It's truly a gorgeous map, although it's in good company as all entries were of a high standard. The community has some great maps to play on right here, and I've no doubt that we'll be seeing more of them in playtests and on servers.
The challenge was fascinating to watch, with the filled with shots of the in-development maps and — perhaps more importantly — members helping one another to create some sweet Unreal Engine 4 levels. In fact, this part of the challenge was so interesting to follow as a non-participant that we're going to try and make the in-development phase of future challenges more prominent by following the progress with articles taking a look at how things are going.
The official Unreal Tournament site picked up on our challenge by talking about it for a few minutes at the beginning of the challenge, and while they briefly acknowledged the end of the challenge in a more recent stream they're apparently still checking out all the maps and will be featuring them more shortly — so stay tuned for that!
I'd like to thank everyone for their involvement, and I sincerely hope that everyone had a good time experimenting with an engine iteration that's still new to most people. Be sure to head over to the to check out and download all of the levels!
We don't mess around at MapCore and want to get one more event in before the year ends, so we're going to be kicking off a Quake 3 contest very soon — this time with substantial prizes, just to spice things up a bit! Hang tight for details about that.