Rebirth

Posted by vincentloignon

Senior Production

Post XIV

After a long an unproductive break, I am back to continue working on The Last Light. I spent all semester talking about it and the development process and I will continue to do so this semester as our game was not cut. This week in particular will be short because it was the first week of classes and nothing interesting happened development wise.

This week, my new humongous team met up for the first time since break and began to talk about this semester. Being the programming lead focused my efforts towards making sure that the 3 new programmers and myself had work to do over the weekend. It was a good opportunity to patch things up and prepare for the upcoming level as the design team and producers scrambled to figure things out. It’s been an interesting experience so far for me since i’ve never really managed people.

What I was able to do so far has been mostly bug fixes. Last semester, I did my best to keep the code clean and bug free, but you can never really iron all of them out. I started with the notorious gate bug where slipping past the gate you have to lift will break your inventory, making the game unplayable. This wasn’t too hard to fix, but it required a little bit of digging to find the problem. The solution ended up being to make sure the inventory was properly re-enabled when the player completed opening the gate. This, however, would be problematic when people snuck under the gate without opening it and would render the code useless. To solve this, I went ahead and put an invisible wall behind the gate which gets automatically removed when you fully open the gate. This makes sure that players can’t sneak under the gate, breaking the systems. Hopefully, this will be the end of the problem.

As for next week, i’m not quite sure whats on the table just yet. I missed the last team meeting due to being out of town and i’m still figuring things out. It does seem like we will be focusing our efforts towards menus and “kiosk” mode as the teachers like to call it.

That is all for this week, but i’ll be back next week with the next segment.

TL;DR:

  • Met with the new team
  • Fixed game breaking bugs!

 

Optimizing and Profiling Games with Unreal Engine 4

Posted by vincentloignon

On the weekend of 11/14/2015, I went to MIGS. This was my first time and it was a pretty cool experience. One of my most memorable take aways from the conference was a talk I went to on the monday of MIGS about Optimizing and Profiling games made in Unreal Engine 4. This talk was done by Epic Games and it was 3 hours of pure information. In an effort to preserve as much of this information as possible, I wrote a ton of stuff down and have committed a lot of parts about this presentation to memory. However, my memory isn’t perfect and in an effort to have more people learn about these really cool and useful tools at their disposal, I have decided to create a lengthy blog post that highlights many of the topics covered at their talk.

Warning: This post is fairly technical and is targeted at people with prior experience working in Unreal Engine 4. It will also be lengthy so you have been forewarned.

Note: This post was written with version 4.9.2 in mind. If you are using an older or newer version, please keep in mind that some this might not be the same.

Tools

Unreal Engine 4 has a lot of tools built into it. Everything you could possibly need to make your game has come to you in a nice package, from particle system editors, animations, sound and more. But some of the tools that might be most important to making your game run well are not as prominent. You might not even know they exist and I am here to show you just a few of the really cool and useful tools at your disposal.

Important: A lot of these tools benefit from disabling frame smoothing. This is a feature which is on by default in Unreal Engine 4. You can turn this off here (Edit->Project Settings->General Settings->Frame Rate->Smooth Frame Rate).

Stats

Unreal Engine 4 has a lot of console commands that you can use while developing and debugging your game. These are accessible in the editor while playing your game by pressing the tilde key (~). You can also access it from the editor at the bottom of the Output Log. To see just how many statistics you can see for your game, just type the word stat and you’ll get over 80 options.

1

I highly recommend exploring different ones, but for now i’m going to show you two useful ones in particular. These are stat unit and stat unitgraph.

2

3

Stat unit will display information on how long it takes each part of your game to process each frame.

Frame is how long it took your frame to do everything.

Game is how long it took the game logic. This encompasses C++, blueprints and the engine itself.

Draw is how long it took to draw your scene (what you see in your viewport).

GPU is how long it took your GPU to do everything that was sent to it.

Now one thing to keep in mind when looking at these is that Unreal Engine 4 by default caps your framerate. This can be disabled in Edit->Project Settings->General Settings->Frame Rate->Smooth Frame Rate. Make sure this is disabled if you want to get accurate results for all the tools, including these. (Note: This should only be disabled in your project if you are profiling/optimizing your project at the time; unless your game needs it to be off. In most cases, this should remain on.)

Stat unitgraph is similar to stat unit, but with two major differences. The first being that the text is now color coded (which I find very useful). The second main difference you might have noticed is that there is a graph. This graph visualizes the information for each frame and can potentially help you determine where things are going wrong when you see large spikes. Spikes also have more information attached to them when they scroll by. A well optimized game will likely have a very flat graph and few to no spikes. This doesn’t mean it is required, it is just a good sign.

GPU Profiler

Sometimes, you need to be able to see what your GPU is doing at any particular time. I don’t know about you, but i’m not able to speak GPU and I need some fancy tools to do that for me. Unreal Engine 4 has a nice GPU profiler which lets you see every little detail about what went on in the GPU on a particular frame. I would recommend using this if you notice your frame rate dropping, or if you see a spike on your unitgraph and want to learn more about what caused it. To activate the GPU profiler, all you need to do is type profilegpu into the console. This may take a few seconds so be patient. When it is done, you’ll see a popup like the one pictured below.

4

The GPU profiler allows you to see everything that was processed by the GPU over 1 frame. At the top, you see a colored bar with the word Scene over it. Mousing over individual segments of this bar will tell you what component it is. The length of the bar is representative of much time it took so things with a larger bar took much longer than things with a smaller bar. Clicking on a bar or the tiny arrow next to the word Scene will start to break things up further. I will use Light as my example, but this works the same for any other component like post processing for example.

If I click the tiny arrow next to scene and click on the tiny arrow next to light, I get to see more specific components to the lighting of the scene. At the bottom, we can see different kinds of lights such as NonShadowedLights, IndirectLighting and ShadowedLights. By clicking the arrows next to these, we can expand it further and see more details. This can go as deep as you want to go. The point being that you can now see how an individual light affects the scene you are currently rendering.

5

6

Another quick example is the Post Processing. If you were to click on it instead, you can see the various steps taken during the post processing and how long they took to complete. In a game where you use post processing a lot, this could easily take up a lot of your GPU time and this can help you pin point the problem.

7

CPU Profiler

Sometimes, looking at the GPU isn’t enough or even what you need. In some cases, we need to look at the CPU instead and see how it is spending its time. We can do this as well in UE4 with two simple commands. Unlike the GPU profiler which is only over 1 frame of time, the CPU profiler is over a duration. You tell it to start, you tell it to stop, and every frame between those two commands will be saved. This data can be loaded into the profiler for extensive looking. To start a CPU profiling session, you want to use stat startfile. To end the profiling session, you want to use stat stopfile. If you need to do this often, it might be useful to make these console hotkeys. If you look in your output log, it will tell you exactly where this file was saved and what it is called. To open up your profiling session, you need to first open the session frontend. This can be found under Window->Developer Tools->Session Frontend. Go to the profiler tab, click load and find your profiling session. This may take a while, especially if you profiled for more than a few seconds. You’ll end up with something like the image below.

8

Unlike the gpu profiler where everything felt fairly straight forward, this one has a bit more to it and might be a bit more difficult to understand. I have gone ahead and marked the sections in the image below and i’ll give a brief explanation of what they do. These aren’t necessarily their official names (I don’t actually know what Epic calls them), but they are named based on what they do.

9

Settings View This view shows you the various ways to organize the information displayed in your function view and event view. For example, if you have selected more than one frame in the graph view, you can show the average or maximum values in the event view. Or if you selected an event, you can view your functions in hierarchical mode.

Graph View  This view shows you the timeline for your profiling session. Lets say that it was profiling for 3 seconds, it would show you 3 seconds worth of data there. If you click or click & drag on it, you will select a section of time to look at more specifically.

Object View  This view shows you everything that used the CPU during your session. This will be everything from physics calls, memory, AI, ticks, etc. It will go down to the individual actor or component in your scene which makes it very useful. By double clicking one of these, like the character controller, it will show up in the graph and you can then use that to determine what was going on when things got slow (visualized by spikes).

Event View  This view will show you all the events which occurred during the time frame you have selected on the graph for all of the objects you have selected from the object view. This view tells you how long each event took to execute, the number of calls and more. If you have more than one frame selected, it either shows the average or maximum (depending on what you have set).

Function View  This view shows you which functions are being called by an event. You can go forward or back through the functions. This shows information such as how long it took, how much % of the event it was. This can be very helpful to pinpoint where the problem is.

I have an example of this below where I selected the Shapes from the Physics Group in my object view. I opened up the GameThread’s FrameTime event which you can see in the function view. This is not a great example simply because there isn’t anything significant going on in the graph view (its all flat). But a good example would be something that has spikes in the graph so you can see what is causing it to spike so much. If it wasn’t clear, spikes are bad.

10

View Modes

Visualizing data is always a good way to prove that something is good or bad. Unreal has some very useful view modes in the editor to allow us to do just that. By default, your scene will likely be on “Lit”. What this means is that it will look like whatever your game will look like in game, lighting and all. But this is far from the only way to view your game from the editor. There are 4 others in particular that I find very useful while developing games in Unreal. They are Wireframe, LightComplexity, ShaderComplexity and Unlit. You can find these view modes in the top left of your view port.

11

For reference, my scene is shown in the “Lit” view mode.

12

Wireframe  This is exactly as you would expect it to be. It only displays the wireframes for everything in the scene. This can be useful to see just how many tris are in a scene and perhaps better judge whether or not something can be reduced. Also useful to see problems with a mesh (although it might be better to do that in something like Maya).

LightComplexity  This shows you how complex the lighting in your scene is. While it might look like abstract art at first, it actually gives a pretty good indication of where you have a lot of lighting overlap and where your scene might have little to no lighting. In terms of perfomance, darker is better so keep that in mind. In the example scene above, I have a few lights placed to help show this complexity better.

ShaderComplexity  This is somewhat similar to LightComplexity execpt it applies to shaders only. You want this to be as green as possible. If you see colors like red or white, you might want to go investigate that part of your scene as this is generally a bad thing. For example in the image above, the glass on the table has a high shader complexity which is likely from its transparency and reflectivity.

Unlit  If your game is generally fairly dark and difficult to see things, do yourself a favor and put your view mode to unlit. It will make working much easier. Unlit mode does exactly as the name suggests; it renders your game with no lighting at all. This has no benefit for improving performance, it is just a suggestion.

Lighting

Probably one of the first things that comes to mind when optimizing your game is your lighting. Lighting can be a powerful tool, especially in Unreal Engine 4. However, depending on how you’ve set it up, it can be very costly and have a huge impact on your game’s performance. There are a few things that you want to know about lighting in Unreal so you can keep your game running smoothly.

For starters, use static lights if you can. Just because you want to light a room doesn’t mean it has to be dynamic or even stationary. If you don’t need to modify the light during game, make it static. Static lights are practically free because Unreal just bakes the lighting and it becomes essentially just a texture. If you are doing mobile or VR, you want to almost exclusively use static lights to keep your framerate up.

Stationary lights are the next best thing you can do when placing lights in a scene. If you need a light to change its intensity or even turn it on and off during gameplay (lots of gameplay mechanics can be derived from lights), this is what you want to be using. But be mindful of the shadows. You don’t want too many lights casting shadows as this destroys your performance. Stationary lights, like static lights are also baked and are very cheap. Just make sure to avoid overlapping more than 4 stationary lights at a time. When Unreal bakes stationary lights, it bakes it in every combination of the overlapping lights being on and off. This is why it limits it to 4. This doesn’t mean you can’t overlap more than 4, however. It just means that any other lights that overlap will become dynamic lights. This can be seen in the editor as a big red X over a light’s sprite in the editor view port (see image below). Note: If you are using a directional light in your scene, this will count as an overlapping light.

13

Dynamic lights should be your final choice of light. If you need your light to move, like a flashlight being carried by your player, then this is what you want. Dynamic lights are the most expensive because the lighting calculations can’t be baked so just try to reduce the amount you need if you can.

I’ve mentioned this before, but it is important to mention again; minimize the number of shadow casters, especially in dynamic lights and point lights. Shadow casting is very expensive and if you have too many, you will have a noticeable drop in performance. It is generally better to have a bunch of static/stationary lights in your scene to do lighting and then a small amount of shadow casters to get the desired effect. Just because you want shadows doesn’t mean you need every light to cast them and there are tricks to reduce this which I won’t cover.

Another thing you can do to improve your performance is by changing point lights to spotlights. This is because what the engine does in the background for point lights is create 6 lights for each direction on a cube which is then used for stuff like shadow casting. This means that it is generally more expensive to have them than a spotlight. If you don’t need a point light and can get away with a spotlight, it is a good idea to switch them.

You also want to be careful of the light’s radius. If the radii is too large, then it will become more expensive to render because the calculations will have to be done to more objects. While this is less important for static lights which get baked (it does increase the baking time), it is more important for dynamic lights and shadow casters. Try and reduce your lights radius as much as you can get away with.

Lastly, you want to be careful about IES textures on lights. This is essentially a texture which defines how to shape a light. You can find this on a light under Light Profiles. A good example of this would be a flashlight. Flashlights aren’t perfect spotlights, they have noticeable rings due to the plastic or glass infront of the actual light bulb. You can replicate this effect on a light with IES textures. Lets say that your artist decided to put a point light in the scene for your flashlight object and used an IES texture to shape it like a flashlight. While it looks great, you might down the road notice that your flashlight is a huge resource cost to the GPU. The IES texture made it difficult to realize that it was using a point light when it could just as easily have been a spot light which would be far more efficient.

Emitters

Particle Emitters are a great way to make games look even better and make them more immersive. Dust clouds in the desert, snow on the mountain tops, muzzle flashes on guns. There are lots of uses for them and lots of ways to absolutely kill performance with them. It is important to just keep in mind a few details when creating your particle effects.

For starters, lower how many particles are being created on the CPU. It is just not a great idea to be using the CPU if you want lots of particles. It will just slow your game down and is a waste of the CPU’s time. Use GPU particles whenever you can.

You should also use particle lighting sparingly. Particle lighting is expensive and while it might look great, it is significantly cheaper to just use a regular light to do that light component. Either replace your particle lighting with stationary/dynamic lights or make sure you use very very few of them. To give an example of this, in one of the games I worked on recently we were using particle lighting for flares. If you had more than 4 flares in the game at a time, your framerate would tank below 40 FPS from 60. When we switched to using dynamic lights (no shadows), we could easily have 20 with no impact on performance.

A useful trick to make particle emitters impact your performance less is to aggressively use LOD.*. This will mean that your game will only have heavy particle use when they are near the camera which is viewing them, meaning you can have more particles with less of an impact.

Another thing you should do is reduce the number of emitters being used in your particle effects. One of the speakers at MIGS gave a great example of a particle effect which looked amazing but absolutely slaughtered the performance. It was an amazing looking muzzle flash that was used in the Infiltrator demo that Epic released back in September 2015. They tried to use it in an actual game for shooting but quickly realized that it killed the performance. When digging deeper into it, they realized that not only were they not reusing the emitters from the particle effects, the effect itself also had 24 emitters. This meant that 24 emitters were being created for each time this effect was used. They eventually reduced the 24 emitters down to around 4, all while maintaining a decent looking effect. This gave a significant increase to performance and it no longer killed the frame rate.

Lastly you should also reuse emitters whenever possible instead of making new ones. Its more expensive to create a new emitter than to just move an old one that isn’t being used anymore. I would recommend creating an emitter pool for emitters which are frequently used; this will have a large increase in performance.

* LOD stands for Level of Detail. It is where you decrease the visual complexity of something the further it moves away from the viewer (in this case, the camera). Mipmapping in textures is an example of this.

Post Processing

Post processing is very powerful and is able to do a lot of useful things for games. It can also take up a lot of time each frame. These are just a few tips to make sure you are getting the best performance from your post processing effects.

You should never use more than one post processing volume in a scene. It doesn’t make sense to do it in the first place and it won’t help. A good way to think about it is that if you pay a guy to paint a room white, it wouldn’t do much good to pay another guy to do the exact same thing to the same room afterwards since it is already white.

If you are profiling your game with the GPU profiler I talked about earlier, you might find your post processing takes a lot of time. While you might think its ok to keep throwing things at post processing, sometimes it isn’t the solution. To make sure you are getting the best performance, only use what you need.

Lastly, be careful with post process materials like Blendables. These are fairly expensive and will likely make post processing an even more expensive operation for your game to do.

Meshes & Materials

It is not uncommon for there to be performance problems with your meshes and materials. While your artists might be good at making materials and meshes that look very nice, they are likely less skilled at making sure these are optimized and run well in game. This is where a programmer usually comes in to help out. Here are some things to keep in mind while improving your mesh and material performance.

Keep the number of bones in your skeletal meshes as low as possible. Your character doesn’t need to have anatomically correct bones.

Watch your vertex count on meshes. Computers in our day and age might be powerful, but it never hurts to use the lowest vertex count possible. Also avoid having creases in your mesh; this is what normal maps are for.

Make sure to use as few islands as possible in your UV maps. If you use automatic mapping algorithms to do the bulk of your UV maps, it is fairly common for them to cause this.

Keep the instruction count in your materials as low as possible. Materials with a higher instruction count will cause a noticeable impact on performance, especially if it is rendered frequently. A good number to shoot to be under for something that tends to have a lot of screen time is around 80 instructions. But keep in mind that the number will be different for every game and platform so don’t think this is set in stone.

Make sure that there isn’t overly complicated vector math in the material. Don’t re-invent the dot product.

Be careful with layered materials. Layers can help make a material look really good but it also comes at a large performance hit. If you can afford to, flatten as much of these textures as you can. Any more than 2-3 layers should probably be reduced.

Be mindful with your translucency, especially with lit materials. These are more expensive to render.

Lastly, utilize the material quality settings. These are there to help you easily swap out materials based on the quality settings in the game. In your material blueprint, just create a Quality Switch node and plug that into the setting you want to change based on quality. For example, you could change the roughness of the material to have more noise at a higher quality.

Blueprints

Blueprints are a great way to do a lot of things in Unreal Engine 4. From small scripts and components to gameplay mechanics and more. The best part is that they are friendly to designers and those who are less comfortable with C++ to do coding. They do, however, come at a considerable cost. On average, blueprints are 8-10x slower than native C++ code. Before you go and say why bother using them, consider the fact that if your code isn’t doing anything crazy, it won’t make a huge difference. That being said, lets see a few ways to keep your blueprints as efficient as you can.

Use event based systems. There is no reason to be constantly polling for information and in a lot of cases, little reason to use the tick function. It is generally better to just setup some event dispatchers and use them instead.

Avoid the tick event. Sometimes, you need to do things on a per frame basis and that is fine, but you should avoid using tick whenever you can. It is fairly expensive for blueprints to be using it and it is likely you could just get away with using events. If you aren’t using tick, turn it off.

Send events directly to actors, don’t query things. Queries are slow and you should avoid slow operations in blueprints when you can.

Reduce the number of components a blueprint has. The more components a blueprint has, the longer it takes to spawn them in the world. Just ask yourself if you need a particular component before adding it.

Lastly, if there is something you want to run fast but still want to write blueprints, consider adding that particular functionality to a C++ function and just calling it from blueprints. This will give the native speed you need for that bit of code while keeping the rest easily accessible in blueprints.

Other Tips & Tricks

I spent a lot of time talking about very specific things and showing a few examples. While this post is fairly long, it only touches on a small fraction of the things you can do to help make your game run better in Unreal Engine 4. While I couldn’t possibly cover every aspect, there are still a few smaller tips and tricks which you can follow to help keep your game running smooth. I just have them listed below in bullet form.

  • Reduce these:
    • Overdrawing
    • Dynamic Lights
    • Draw Calls
    • Shadows (These really kill performance so only have them when necessary and try to reduce how many shadow casters there are if possible)
    • Material Instructions
  • You can turn things off while in game with the command show (i.e. show particles). You can also do it through the editor in the top left where it says show. Turn off things that you don’t need while looking for a specific problem to help narrow it down quicker.
  • Use stat unit & r.screenPercentage 10 to help determine if you are CPU bound or GPU bound. If your FPS goes up, you are GPU bound. If it stays the same, you are CPU bound.
  • Make your UI event based instead of binding (binding kills your performance, especially if used often)
  • Take a look at Epic’s documentation for Unreal Engine 4! There is a lot of really good information there and it is only getting better with time.

The Last Light – Post Mortem

Posted by vincentloignon

Senior Production

Post XIII

As you could probably tell from the title, this is a post mortem of my project this semester. A lot has happened in the past few weeks and I’d like to spend a little bit of time to talk about my reflection on that time.

This semester, my team and I decided to create a game we call The Last Light. Being a narrative driven survival-horror game, we knew going in that it would not only be difficult to pull off, but it would also likely be large in scope. This doesn’t even take into account things like my experience in Unreal Engine 4 (I started with no experience whatsoever), or even the likely hood of our kind of game making it through to next semester (historically, narrative games and horror related games don’t do so well, we were both). The deck was stacked pretty high against us. But this didn’t stop us. We put our hearts into the game and the result, I think, is pretty good. The process, however, wasn’t without its problems.

So the biggest problem for me at least was not knowing the engine. This meant that I had to spend a considerable amount of time learning and getting comfortable with it. That ended up being a month due to how my work schedule panned out. I probably could have done it in a week if I was able to actually work on the project like a full time job. It felt like a very long month in my eyes and my work felt very difficult because I knew nothing. Luckily, everything eventually clicked and I was able to do work an order of magnitude faster; but for a few weeks, I was definitely concerned about my choice to do this.

The other problem for me was the genre of our game. I’m fine with narrative based games and survival games, but horror really isn’t my strong suite. I don’t really like to play horror games and I certainly don’t like to be scared. This initially seemed problematic for me, but I realized as I continued to work on the game that it wasn’t a problem at all. My work focused on systems, tools and a little bit of gameplay and I almost never dealt with anything scary. On top of that, it turns out that like a lot of things, you get de-sensitized to it after a while. My group all had this problem with the project. After a little bit, we were no longer able to tell if things were actually scary or if they just seemed cheap and bad. We relied heavily on feedback from people outside the group on whether or not it worked because we had no real way to gauge it.

As for the team, I think we worked pretty well together. There wasn’t any personality clashing and everyone was reliable. The work got done and with a good level of quality from everyone. Going in, I was definitely afraid of ending up with team mates like the ones I had previously in production 2 (lets just say, it was bad). I am very happy with each and every member on my team and It was a pleasure to work with them this semester.

But what does this mean for the future? Well, seeing as our game made it into next semester (apparently we are the second horror game to ever make it at Champlain), we have a lot of work to do. This means that our team will soon be expanding, potentially 2-3x larger than it currently is. Our goals for next semester are just as ambitious as they were this semester, but somehow I think we’ll be able to pull it off again.

Wrap Up

Posted by vincentloignon

Senior Production

Post XII

The topic of this week’s post is actually about things that went on last week before presentations. I avoided posting this last week simply because I was already overwhelmed by capstone as it was and I didn’t feel it necessary to post it immediately.

During the last week of crunch before presentations, a lot of important features were added to the game which improved the gameplay. The build also had a large amount of progress made on it because we had less than a week to finalize our game and presentation. One of these important features was an update and fix for the Light Dampening Volumes.

In a previous week, I talked a little bit about the Light Dampening Volumes and how cool they were (they still are). However, one thing I noticed while doing some updates to the flare was that they were fundamentally flawed in their execution. This had only recently manifested itself as a problem because of some of the things that we needed to do. In this particular case, I was transitioning the flashlight and flare to use a timeline for their light intensity so chris can make them look pretty and do cool flickering stuff when they are close to dieing. What it boiled down to was this. The volumes would detect and store when holdable light sources such as the flare would enter. They would also smoothly interpolate to a dampened light intensity by directly modifying the intensity of the light source and just keeping track of these values in the volume. At the time, this was fine because the light intensities never changed nor needed to change. However, with the use of a timeline to modify the intensity of the light over its lifetime, this became problematic. The solution? A good ol’ refactoring.

I decided this was a good opportunity to re-organize this code as well as bring it to C++ instead of blueprints which is what it was originally. I essentially took a bunch of the functionality from the volume and put it in the Holdable Light Source class instead. It made more sense for a light to manage its own intensity and how much it should be dampened. The volumes would still keep track of what lights entered them and how much to dampen the lights. The main difference is that the lights themselves would interpolate their intensity based off a dampening value which could be added/subtracted to them. What does this mean? It means that now you can do something like flicker a flash light by messing with its intensity in a timeline and have that intensity be further dampened by the light volume. You can also completely reset a light’s intensity back to its original, un-altered values which are stored when a light is created.

The UI was also updated during this week. Previously, our game only had the popups which indicated which buttons to press to do things. While these were useful, we decided to keep them turned off by default and are still there for those who need it. This, however, didn’t tell us anything about our items like the flashlight. One of the things that was annoying is that you had no way of knowing how much battery your flashlight had left. This is where our new UI comes in. We still wanted to maintain a very minimal UI and the result is shown below. The main problem we had was there wasn’t enough time to iterate on the UI very much and get feedback so it is fairly un-polished, but it portrays the information fairly well.

The Flashlight

21

The Flare

22

Another major change to the UI was the inclusion of tooltips. Another problem our game had was that it wasn’t necessarily clear how the player was supposed to do things in the game. Even simple tasks such as picking up a flare or opening a gate were suddenly difficult. This was partially due to hiding the popups by default and also due to design choices. We needed something that could tell the player the information they needed in a way that wasn’t too intrusive and was minimal. Our solution is the tooltip system seen below. I took inspiration on its look from how Amnesia did a similar system. When you look at or do something for the first time that has some sort of tooltip, it will fade in the text, hold it for a few seconds and fade it out. A tooltip only ever happens once, so you can’t get the same one twice. You also can queue them up and it will display them in the order that they were triggered. The system could likely use some tweaks such as the speed of the fading and other small things but it was an overall great addition to the game. It gave us the chance to tell the players important information without being too invasive to the play space and without seeming out of place.

23

In other news, a few important bug fixes happened during this hell week. Simple things like flares no longer breaking the inventory when being blown out by a wind volume, scripted event triggers going off just by a player looking at them (while standing close but not in them), and even fixing a bug with flares breaking light volumes. Man it sure seems like flares are the problem child.

Since I wrote this after the presentations and after the results were released, there is a tiny bit more to mention. On Monday, 11/23, my team presented The Last Light to a large group of faculty, students and family members. We demoed our game the following night to the faculty. We were thrilled to find out Tuesday night that our game had indeed been chosen to move on into the next semester. It is a large step for us because we were a narrative driven survival-horror game and if history told us anything, it told us that our game had a bad chance at making it through just by the genre choice alone. However, it would seem our game went through because we presented it well, our prototype was solid, we knew what we wanted and we know what needed to be done next semester. That being said, I am sad to see some of the games get cut because there were a few that I thought were cool and didn’t make it.

This concludes the post for this week which was actually last week. I will be posting a post mortem in the near future about this project. Keep an eye out for that if you are interested in those kind of things.

TL;DR:

  • Fixed Light Dampening Volumes by refactoring them into Holdable Light Sources
  • We added some UI for items
  • We added tooltips to the game
  • Fixed some pretty nasty bugs
  • Presented and demoed our game
  • We made it into next semester!

MIGS

Posted by vincentloignon

Senior Production

Post XI

The title says the bulk of what this post will cover. I will also briefly talk about some of the small updates I’ve made in my minimal time to work on the project since last week. Oh and let’s not forgot where my team is in terms of stages and the upcoming presentation day (less than a week away…).

This week has been a bit hectic on my end. My networking project which was turned in last Thursday ate up the first half of my week with two days in a row of near sleepless nights. Adding on top of that the fact that my Friday has work until dinner, it meant little time to work on things. I did, however, manage to get a few small quality of life improvements to the game. The first of which was toggling the popups. Our game has been using somewhat temporary UI popups to help the player understand what they have to do while playing the game. I’ve shown them in many posts previous to this and while they are incredibly helpful, they are also incredibly immersion breaking. I personally didn’t want to get rid of them and after some talking, we decided to keep them as a “tutorial” style feature, kind of like training wheels. The player will be able to turn them on/off at will and it is there if they need it.

The second part of these changes was the addition of a way to tell if something can be interacted with. Since our previous method involved the UI popups, we needed something more ingrained into the world. Our final decision was an outline when you could interact with objects, similar to what a lot of other games like Left 4 Dead and Evolve used to make it easy to spot. You can see this in action below.

The Flare Box

19

The Gate

20

Now that I’ve covered all I was able to do, lets talk about MIGS. I wasn’t originally planning on attending the conference, but about 2 1/2 weeks ago i received a surprising email. I had applied for a free pass to MIGS back in September through their website. They were going to give a free pass to a select few “job seekers” and I ended up being one of the selected few. This meant a huge shift in my plans and was quite a nightmare scheduling wise since I effectively had 2 weeks to plan my trip. I left Saturday, and arrived Tuesday in time to go to 2 out of 3 of my classes. Without access to a powerful enough computer or two monitors, my resources were limited. Not to mention the entire point of the trip was to spend all day at MIGS trying to get a job and to go to sessions. Sunday was incredibly exhausting with several hours of talking to recruiters and developers about job opportunities and later that night following up with every one as well as applying to what felt like a million job positions at those companies. Monday was less crazy since I had talked to most of the companies with positions I was interested in and I had a great opportunity to attend a session on profiling and optimizing UE4 projects. This was probably my favorite part of MIGS (not that I didn’t enjoy all the conversations I had Sunday!).

What does MIGS have to do with my senior team? Well I think that I learned a lot going to the conference, even excluding the talk about UE4. I was able to ask questions to some of the developers about some of the things they did to tackle similar problems in their games that I’ve had in the past. I also went to that UE4 talk which was 3 hours of pure information and I learned an enormous amount of very applicable information. It finally taught and showed me what I can do to improve the performance in our game and what common pitfalls to avoid while developing it. What helped make this even more useful was the fact that at this point, I feel very comfortable in UE4.

Last week we challenged the Proof of Concept Stage and passed into Vertical Slice. That was also the time we learned we would have to challenge Vertical Slice to be guaranteed a spot to present this coming Monday. This was contrary to what we had previously heard from other professors and students and has my team slightly concerned. That being said, we can still present with permission and it is our intention to ask for it. This was also a sudden change in plans for us and due to the difficulties of attempting to get all the required materials for a challenge by tomorrow (which was impossible), we’ve decided to continue focusing our efforts towards the presentation in the hopes we get to actually present our game. This is all I have for you this week, tune in next week for what will likely be an update on where our game is for the presentation.

TL;DR:

  • UI popups are now toggleable
  • Interactable objects now have a highlight (like Left 4 Dead)
  • I went to MIGS and couldn’t do much homework
  • I learned a lot about UE4 at MIGS
  • We are petitioning to present

The Storm

Posted by vincentloignon

Senior Production

Post X

This week’s update focuses on the storm of updates to our game since last week. The title fits the amount of content we’ve pushed into the game since it was last shown, especially on my blog. I have a few things to talk about first and then i’ll finish up with a little about our stage challenge.

Towards the beginning of my updates on friday, I was able to add more features to our existing systems. Holdable items were now able to have infinite quantity which is used on items like the flashlight which aren’t restricted by a quantity. Holdable light sources were able to have time added to their duration. I also added some visual feedback to things such as the gate and reloading the flashlight (which it didn’t previously have). Another major update that came out of this a system for doing voice lines in C++ while keeping some of the more specifics in Blueprints. This means that I can call a function in the C++ code which tells the player to say a sound and I can specify which sound using an enum. Then in the blueprint, i can override this function and define what sounds to play based on the enum i passed. The list goes on a bit more. The main point is that friday added a lot of updates to some systems in place that made future content easier to do.

The gate now shows “HOLD” with the E key to better instruct the player

16

Another shot of the gate. This also shows the fixed flare which you can now see even when not looking directly (this was a bug before).

17

HOLD R to “reload” the flashlight which recharges it by shaking

18

There were some major bug fixes which all also happened this weekend which fixed some of the larger problems which “plagued” our game. This included things like fixing our liftable gate to not break things with the inventory, improving the circuit box’s interaction, being able to see flares when not looking at them, general flare improvements with the lighting, and most importantly of all,  I fixed the game breaking bug we had which would crash the game. If you are interested, the moral of that story was essentially this: If you don’t want your variables being deleted every 60 seconds or so by the Garbage Collector in what seems like seemingly random events, and if you also don’t want the largest pain in the ass debugging nightmare, then always put a UPROPERTY tag over every single variable in your C++ code. It is a hard learned lesson as this bug has been in our game for weeks now with what felt like no foreseeable fix.

This week also focused a bit on the darkness and the scripted events for it. While I did not implement most of the code in the scripted event themselves, I provided some useful actors and code which is to be used in conjunction with the event. In particular, i created an actor called a Light Dampening Volume. This actor is placed in a level, you customize the volume for it which defines where it affects light. When a Holdable Light Source enters the volume, it is dampened by a percentage which is defined by the volume (can be customized on an individual basis). This will be incredibly useful in the near future as we start implementing more scripted events and need this kind of behavior for the darkness. You can see it below in its original form (which was instantaneous) and its updated form (which linearly interpolates to the desired dampened value).

Instant Change

light_dampening

Gradual Change

 

light_dampening2

While these images show a drastic change in the intensity of the light, this was purposely exaggerated to demonstrate that it works. The amount the volume would actually change could vary based on what the darkness is capable of doing (due to progression) and what is necessary for scripted events or even levels.

Lastly, I’d like to briefly talk about our challenge. This week, we are challenging the Proof of Concept stage. If we pass, this will put us into Vertical Slice and make us eligible to present in roughly two weeks to have a change of moving forward into next semester. This is a very big deal for us and we are hoping that our challenge goes well. This is all I have to show for now this week but before I go, I have an updated video showing off our current game. Enjoy and tune in next week for more updates.

 

TL;DR:

  • I added lots of cool features to the systems
  • I added visual feedback and quality of life improvements
  • I created a system for voice overs
  • We can now dampen light held by the player (including dropped flares)
  • We are challenging Proof of Concept!

The Calm Before the Storm

Posted by vincentloignon

Senior Production

Post IX

 

This week’s post will be relatively short as I have little to show for it. I have been incredibly busy this past week with a midterm project for Mobile Devices and my Networking assignment. Add the fact that I was away for most of the weekend, It has left little time for Capstone. Not to say I haven’t done anything! This week’s focus since I have been busy in my other school work has been on planning for the upcoming weeks. The intent being to focus my efforts in the next two weeks before our upcoming challenge and hopefully our presentation.

We have recently been working on the design of the vertical slice level and what the shadow will be. Since we decided to make the shadow scripted (for the time being), Chris created some documents which outline the different scripted events, what they do and so forth which will be used to craft them. We have also laid out the features we want to try and have by the presentation which is coming ever closer. My primary focus in the coming weeks is patching up the inventory system to be feature complete. This includes fixing the game breaking bug which involves items/inventory and making it so items are limited. I will also be implementing reloading for the flashlight, functionality for voice over lines and most importantly some scripted events for the shadow.

I’m going to purposely leave this post short since there isn’t much else to write about. This week has been pretty bad for me in terms of workload and stress and there’s sadly been no time to do work on Capstone. This coming week will be a different story since we plan to challenge the proof of concept stage next week. This week is what i’m calling the calm before the storm, despite the fact that it is already a hurricane in terms of work. Tune in next week for more info on the stage challenge.

TL;DR:

  • I planned my next two week’s priorities
  • I did nothing else this week for capstone 🙁
  • We are challenging next week

Systems v2

Posted by vincentloignon

Senior Production

Post VIII

This week continues a similar trend to the previous week. Most of my efforts have been focused towards continuing to build and improve the systems in our game. Being a huge fan of cool systems and hierarchy based systems, i’ve been going nuts over the structure of everything. Sadly, a lot of the work is in the backend and is hard to show, however, there is a bit of gameplay features that are new to the game as a result of these systems being developed which I will show in this week’s post.

For starters, lets revisit the topic of interactable objects and the inventory. I have overhauled these systems a bit this week and some of the improvements include being able to remove items from the inventory, being able to drop items, more functionality such as handling events like being equipped/unequipped, being dropped and more. The player is also capable of reloading items which is a feature used by the flares (and soon to be flashlights) to turn on the flare (essentially striking the flare with the friction cap to ignite it). Another feature (although still needing improvement) is dropping items. While still in its early stages, it is important to the gameplay. I could keep rambling on about the systems, but seeing as there isn’t much to show for it (visually speaking), i’ll skip to the more visually interesting things.

One of the features which was added last week was the ability to interact with objects properly using E. You would see this popup on your screen when you looked at an item which was allowed to be interacted with. An example of this was the box of flares which would give you a flare to use. This week, I was also able to add a feature called reloading. In our game, there will definitely come a time when you need to “reload” your flare or flashlight because they ran out. And since flares don’t just magically start lit up, this was how we would start a flare. In terms of the flashlight, this would bring you to a small “minigame” per say where you would need to perform an action to recharge your battery. I also managed to get an important feature working in our game which is the ability for light sources to be expendable. Previously, they were infinite only because I hadn’t gotten around to it yet. This was further pushed on the flashlight specifically giving it a flickering which shows up when the batter is low and an increased flickering right before dieing. A neat little feature which will hopefully inform the player of the time left with their light without needing UI. Below are a few gifs of these actions. I apologize in advance for their terrible quality but i’m not exactly very good at doing gifs.

Flare Dropping

drop_flare

Flare Reloading

reload_flare

Flicking Flashlight

flickering_light

As for the challenge we did last week, the good news is we passed and are now chugging towards reaching the Vertical Slice Stage. The obvious bad news is that we have a lot of work ahead of us if we want to make it to that stage. We are all excited to have the opportunity to push forward into next semester and are definitely hoping that we will be one of the games chosen to move on after the “cuts” in a few weeks.

Tune in next week for more updates on my progress with the prototype. This coming week will likely involve further pushing our existing systems to create mechanics as well as fixing some nasty item bug which is causing the game to crash. Oh the joys of programming.

TL;DR:

  • I made more systems and improved existing systems
  • Light sources are expendable
  • Items can be reloaded
  • We passed our challenge
  • We have a game breaking bug 🙁

Systems, Systems Everywhere

Posted by vincentloignon

Senior Production

Post VII

14

Seeing as the topic this week is systems, I figured i’d start out the post with a meme. Woody’s face is quite reflective of just how much there is to make systems wise. Jokes aside, there really is a lot going on in the backend of our game and I’d like to take a little bit of time to talk about some of the cool things i’ve done with it this week.

For starters, our interactable object system which I talked about last week is more or less done and in working action! The system will create a small interface button which indicates what button to press to interact with the object. This can be toggled on and off at the designer’s leisure and the code that defines what to do when an object is interacted with is left open ended to be whatever we want. You just override a function in blueprint and do what is needed. For example, a flare might delete its instance in the world and add a flare to the player’s inventory.

15

Speaking of inventories, there is now a working inventory system. While it is still in a primitive state and only allowing basic functionality such as add and switch, it is built to allow flexibility across the board. Much of the functionality is open to blueprints despite being C++ based and it is very easy to work with. This will be an important system for the game. It is, however, lacking a few features that will make it even nicer. For example, it currently doesn’t store important information about the objects stored in it, such as how much time is remaining on a light object. This will be improved on further in the near future. A system for defining behavior in regards to an item such as when it is allowed to switch off and what to store when switching is also something i’d like to get in. This would allow each item to behave independently of each other while still making it so the system handles everything. An example of this would be the flare not allowing you to switch to another item while it is lit, but you can drop it or throw it still while a flashlight might not let you drop it, but you can switch whenever.

Another system i’m looking to get into the game is dropping and throwing items. While the prototype does currently feature these, they are very hacky and are in no way written to be good. They were thrown together for testing and will be re-worked to work with existing systems. Currently, these are on the backburner. While they are important to the game, the inventory has a higher priority and it is likely the inventory will provide a lot of functionality useful to these tasks.

While I would like to keep talking about the systems and all the fun stuff I did in C++, there is another important topic at hand which I didn’t mention earlier. This being our stage challenge this week. We’ve worked hard during this stage to figure out our game, do research into topics that will help our game and push our prototype further. We believe we are ready to move on to the next stage and hopefully this will be the result of our challenge tomorrow. It is also important to mention our game now has a working title! It is currently being called The Last Light and the narrative has made some changes since its original incarnation. While I won’t go into those details in this post, I might revisit this topic in a later post.

I have prepared a small video showing the current prototype. It features a new level which better fits the direction our game is currently moving in than the original level we created. I did mention it in my previous post and so you should read that if you want more details about the level.

TL;DR:

  • I’ve been doing a lot of systems
  • Interactable objects work
  • Inventory works (on basic level)
  • We are challenging the next stage
  • We have a new level!