Watching Blueprints

While playing the game, you can press Shift + F1 to regain the mouse without having to exit the game. If you then switch to one of your Blueprints, you can see when events are triggered.

You can also right-click on variables, inputs, and outputs and watch variables while the game is running.

Print String

The <Print String> is a very useful node for debugging your Blueprint systems. You can use it to print text or variables to the screen as you play the game in order to check your systems are working correctly or that variables are in the ranges that you are expecting. In this example, the <Print String> is printing the physical material that is obtained from a line trace within a footstep system (the name of the physical material has been converted into a string by the <To String (Object)> node.

This enables us to monitor and check the physical materials that are called as the player walks around the level.

If you have multiple <Print String> nodes running simultaneously, it can sometimes be difficult to keep track of which values are being printed to the screen. A useful solution to this is the <Format Text> node.

This allows you to build a string (as text, so will need to be converted to a string using a <To String (Text)> node), using specifiers.

In the example above, the specifier is health ({Health}). This creates a second input to the node (Health), and so the final output to the <Print String> node in the example below would be “Player Health = 100” (if the player’s health were 100).

Auto-Save Recovery

As you can get absorbed in work and forget to save regularly, the Unreal Engine has an auto-save feature. The default setting is to auto-save your maps and content every 10 minutes, but you can change these settings via the Edit/Editor Preferences/Loading and Saving menu.

The files are saved here:

PC: C:UsersUserNameDocumentsUnreal ProjectsProject NameSavedAutosaves

Mac: /Users/UserName/Documents/Unreal Projects/Project Name/Saved/Autosaves

If the worst does happen, then you can copy the auto-saved map back into your project maps folder:

ProjectsProject NameContentMaps

Although this can be useful in an emergency, we would not advise relying on this too much, so get into the habit of making your own regular saves—don’t forget to use incremental file names!

Organizing and Commenting

We talked quite a lot in Chapter 00 about the importance of establishing folder structures and naming conventions for your assets early on in a project to help you keep track. This will enable you to find and recognize assets quickly and make your work a lot more efficient.

In addition to using folders and sub-folders in the Content Browser to manage your assets you can also use them within the World Outliner to organize your in-game Actors. For example you might use named folders for each location in the level to group the Ambient Sound Actors in that area.

As your system become more complex, it becomes harder to remember what different sections are for or do. It makes sense to add comments to your sections to remind you when you come back to them. For in-game systems and areas, you can add a <Note> Actor to your level, and then within its Details panel you can add text to the Note/Text property. If you change the name of these notes as well, you can search for them in the World Outliner.

Within your Blueprints, you can add comments directly to individual nodes by right-clicking them and typing into the Node Comment box.

You can also select multiple nodes and press C to create a comment that encompasses them all. This is useful for separating out your different subsystems and marking up sections so you know what they do.

Working in Separate Audio-only Levels

When working on larger levels or projects or within teams, implementing your audio in your own audio levels is a good working practice to get into, as it means that you can be working on your audio systems separately from the level designers.

It is pretty easy to set up multiple levels within a single project in UE4. Simply open the Levels window (Window/Levels), and then from within this window, use the Levels menu and Add Existing or Create New, depending on your needs to either add your existing audio level or create a new empty level within the project.

All available levels within the project (i.e., ones that have been added) will be displayed within the Levels window.

The next step is to set up your [Level Blueprint] to stream your levels (i.e., load them in) as and when necessary.

The image below shows how you would use the <Load Stream Level> node to load in an additional level as the main level starts.

The next image shows how you might use an in-game event to unload one level (using the <Unload Stream Level> node) and then load in another one. This technique can help to free up memory resources in larger levels, as you only stream in the audio assets as you need them.

Unfortunately there isn’t really a direct way of passing variables and events between the persistent level and those that are being streamed in and out. The best approach is to use either an external Blueprint (e.g., the [Game Mode] Blueprint) as a way of storing global variables or calling events within the different level Blueprints.

Here is an example of how this might be done.

In the main persistent level, an in-game event gets a reference to the game mode and <Cast>s it to its parent class and then calls an event within the [Game Mode] Blueprint.

In the [Game Mode] Blueprint, the <Custom Event> then <Calls> an Event Dispatcher.

In the streamed level, an <Event Begin Play> <Casts> the game mode to its parent class and <Bind>s an event to the Event Dispatcher, which is triggered by the in-game event from the persistent level.

This seems quite complex but is actually the same process discussed above in Appendix B/Communicating between Blueprints/Casting and Appendix B/Event Dispatcher. It’s just that we’re doing it between three Blueprints rather than the usual two. In summary, the in-game event triggers something in the persistent level, which in turn triggers something in the [Game Mode] Blueprint, which then triggers something in the streamed level.

Tips for Slow Running

If you find that UE4 is running slow while you’re editing your levels, there are a few things that you can do.

Disable Realtime Rendering

From the Viewport Options, disable the realtime options. This will prevent the engine from trying to constantly update the Viewport display (Ctrl + R will toggle this on or off).

Far View Plane

Also in the Viewport Options, this is set to 0.0 by default and means that there is an infinite far view plane so all objects are rendered no matter how far away they are. You can set a different value to reduce the rendering load as fewer objects are rendered.

Build Lighting

Ensuring that the lighting build is kept up to date can help reduce the load on the CPU as you edit your level, as it does not have to generate temporary textures.

Engine Scalability Settings

From the Settings icon across the top toolbar, access the Engine Scalability Settings, and from here you can scale down some of the video settings to make things a bit more responsive.