Notes and Tips on Getting Started with Unreal Engine (my notes follow after my infographic)

Getting Started with UE4 Infographic.svg

getting_started.md

Notes and Tips on Getting Started with Unreal Engine

These are my notes and tips from completing the Unreal Online Learning Challenge of Fall 2020, which included the following courses:

• Build a Detective’s Office Game Environment
• Converting Blueprint to C++
• Creating Photoreal Cinematics with Quixel
• Ambient and Procedural Sound Design
• Dynamic Audio

General Tips

Here are some important tips that apply to UE4 development, in general:

• Naming conventions are essential for every aspect of your project. They help keep things organized and many parts of the engine enforce them. So, start following them early in developing your game and stick with them. Your team (and "you" in the future) will thank you.
• All assets (static meshes, textures, and audio files) require prior planning so you and your team knows what needs to be built and where it will be used.
• When creating physical spaces, be sure to place mannequins/humans in the scene early to properly establish scale.
• Use real-world reference material and mood boards to establish the look you're going for before diving it. There's no substitute for good reference material.
• Assets a player interacts with most often -- for example sounds (like footsteps) and static meshes (like rocks and landscapes) need the most variation to avoid becoming monotonous and breaking player immersion.
• Do simple things before complex things! Start with rough ideas first; fine-tune later. Some examples:
  • Block out your levels and test flow with simple shapes before investing in higher-detail meshes and level layouts. This ensures you can root out problems early and correct them without losing a lot of time reworking assets.
  • Start with Blueprint before moving into C++, since it's easier to prototype and playtest there with designers than it is in C++.
  • Consider using less-sophisticated approaches like sprites and cards or toggling sounds on and off before having to crack out more sophisticated approaches like photo-realistic fog and audio occlusion. Simpler solutions are easier to understand and tend to perform better; depending upon the needs of your project, they can often look and behave just as good.
  • Adjust lighting and post-processing affects at the end, not at the start, to avoid getting overwhelmed by all the options or getting stuck in analysis paralysis, tweaking so many aspects of lighting and post-processing that you lose track of what you're doing. Adjusting lighting and post-processing at the end also avoids having to re-do a lot of the texturing and lighting of individual assets later when you find they don't work in the variety of lighting conditions you need for your project.

Notes from "Building a Detective’s Office Game Environment"

• Start from a mood board and existing photos that exist in the world to establish the visual aesthetic you're aiming for before you start blocking things out and creating meshes. Inconsistent art direction at the start will bleed through to the final product.
• Asset creation is iterative! Don't think that the assets you create in programs like Maya and Blender have to be perfect before they can be imported into UE4. Instead, if you export into FBX format, UE4 makes it possible for you to export rough assets and iterate on them. As long as you keep exporting assets to the same files in your project, UE4 will automatically re-import them without you having to re-enter settings, making iteration very quick/easy.
• This course throws a lot at you and doesn't do a very good job at explaining the "why" of things like power-of-two textures or why different types of lights are expensive. Don't be afraid to dig into the docs to get the answers to these questions!
• On that note, use point lights sparingly since they project rays of light in all directions in a scene. Other types of lights -- including rectangle lights -- can produce similar results but are often more appropriate for the situation while performing better.
• If you can't afford Maya, there are plenty of other packages that also export FBX, including Blender, that are just as good!
• This course doesn't really show how to properly clean-up references in Blueprints, but you should. In the interest of speed, the instructor left a lot of content from the first-person starter project hanging out, unused (sometimes referred to as "dummied out" content). This is technical debt that you'll want to clean-up in a larger project.

Notes from "Converting Blueprint to C++"

• Don't assume that your game must use C++ for acceptable performance. Blueprint is often fast enough for most games! Use profiling results to tell you which parts of your game -- if any -- need to be moved into C++. It's also not all or nothing -- your game can use Blueprint where appropriate.

• Proper logging is crucial to debugging problems during playtesting, but too much of the wrong logging can make it hard to see the forest for the trees. In this course, the instructor used "Warning" log level for all logging statements. In a larger project, though, you should use the log level that's appropriate for the severity of the issue. In almost all of the cases where logging was used in the course, a "Debug" log level is much more appropriate and less likely to spam you with spurious information.

• There's an important point that was glossed over by both the instructor and the quiz: functions can only be considered "pure" if:

  1. They can be called at any time; and
  2. They don't have side effects (they just return values without affecting other things in the scene/blueprint).

  That's why these can be "const" functions in C++. (Just saying it "doesn't have an execution pin" oversimplifies things and doesn't go deep enough).

Notes from "Creating Photoreal Cinematics with Quixel"

• When starting out, use reference photos and photoshop to pick the mood and colorization you'd like to aim for before eyeballing it/starting to play with post-processing in UE4. Otherwise you can get overwhelmed by all the options.
• As mentioned above, do simple things before complex things. Sometimes the best-looking solution is actually the cheapest solution for implementation, as was the case with the top fog cards to simulate ground fog that moves, and using particle effects in the canyon to simulate speed.
• If lights and fog volumes move together, you may need to adjust "reprojection" to ensure lighting calculating keeps up.
• If your budget allows, consider leveraging "virtual cameras" with real cameramen to get realistic-looking camera movements in the virtual world.
• UE4 has all the tools you need to create photo-realistic scenes and big-budget movies without even having to use ray-tracing or separate software.
• Megascans give you the assets you need at a reasonable price without needing to do 3D scanning yourself.

Notes from "Ambient and Procedural Sound Design"

• Both Quiz #1 and Quiz 2 have some awkwardly-written questions; they need some revision. Also, some questions are in the wrong part (a part 2 question is in quiz 1).
• You can set camera location shortcuts with CTRL + 0-9, and then press 1-9 to use them.
• Always audition sounds the way the player would (normal player walking speed) to get a realistic sense of how things will sound.
• Turn off spatialization for ambient noises if the panning effect of the sound would be distracting to the player. Or, for a 5.1 audio game, consider shifting it so the player only hears it in the rear channels.
• Create and re-use sound attenuation assets if you have things like fire or water that need to repeat throughout your level so you don't have to manually set attenuation to each instance. Consider incorporating the audio into the fire actor to make things even easier.
• To enhance immersion, use "play when silent" for sounds that the engine should keep track of even when the player is not nearby (e.g. bands, music, or distinctive ambient sounds that should not start from the beginning upon approach).
• The virtual loops update rate may need to be adjusted so that sounds play at the expected time if the player/the camera is moving quickly.
• Triggers that simply fade-out sounds or turn them on or off can provide a cheaper, more performant alternative to audio occlusion volumes.
• (This was in the part 1 quiz but covered in part 2) Double-click a portion of an audio cue to audition that part of an audio cue graph in isolation.
• Leverage weighted randomization to cause some sounds to happen more rarely than others. Combining that approach with inputs that have no sounds attached can even allow you to control how often no sound is heard for part of a sound cue, adding further variety.
• Splitting a long sound or similar sounds into their component parts and mixing them together with modulation and looping in UE4 is often more impactful and versatile for creating an immersive environment than having to invest in a large library of sounds.
• When using an "enveloper", ensure that the volume never drops below zero or the sound will stop playing abruptly.
• An enveloper can be made longer or shorter than a sound to smooth the way that an otherwise abrupt sound fades/mixes into the scene.
• Use Blueprint Actors to create re-usable logic and actors; for example, collision volumes or even static meshes that are coupled with sound effects that trigger when the player interacts with them.
• Consider using player-oriented sound triggers instead of placing lots of one-shot audio cues throughout a map. It simplifies level design, especially for sounds that need to come from many different, random directions (e.g. birds, rain, etc) relative to the player's location.
• When in doubt as to where a sound cue is being created, visualize! Create a physical object where the cue is being created in the world, to help with debugging.
• You may need to leverage "Event Begin Play" to add additional trigger logic if a player could spawn inside a collision volume; otherwise, sounds that the trigger starts might not start the way you expect.

Notes from "Dynamic Audio"

• Sounds the player hears most often (e.g. footsteps) need the most variation to avoid becoming monotonous.
• Create a re-usable parent blueprint for collision volumes that are triggered on player input (e.g. pressing the "E" keyboard button) so you don't have to repeat this for every NPC.
• To prevent new lines of dialogue from overlapping ones currently being played, leverage "bind event on audio finished" combined with a "do once" at the start of the blueprint graph so that logic to play new sounds doesn't run until the previous line of audio has played.
• Curve Float Variables (Timeline graphs) can be leveraged to give you fine-grained control over how and when different sounds are triggered in a Blueprint and how loud they play. They can even control how different sounds cross-fade based on inputs like the intensity of running or intensity of a collision.
• Put sounds (or any element, really) in a variable if you need to reference them from multiple places in the same Blueprint, to keep the graph tidy.
• Consider moving variable-based branching logic that triggers sounds into sound cues to keep level blueprints tidier and more focused. This keeps each concern cleanly isolated/separated.
• The "Map Ranged Clamp" Blueprint action is very useful for mapping values from one range of numbers (e.g. integers 0 to 255) to another (e.g. floats from 0 to 1). It can also be used to invert the output, so that as one set of values increase, outputs decrease. "Normalize to Range" is another, similar tool for converting one range to another.
• If you are spawning many sounds for the same thing, considering using a concurrency "Max Count" with a Resolution Rule of "Stop Oldest" to prevent using up all available voices (there are usually a max of 32 voices).
• UE4 provides all the tools you'd expect from a Digital Audio Workspace (DAW) tool (esp. using sequencer for audio tracks). It supports looping, crossfading, multiple tracks, and more!
• If a sequencer sequence can play backwards or forwards with sound, create Events tracks for each direction of playback in Sequencer that fire sound events on the affected actor(s).
• The "Audio3dVisualize" console command can be used to "show" the positions of sounds in 3D space.
• You can add sounds to animations via "Add Notify" -> "Play sound" in the animation designer.
• Use a "Notify Trigger Chance" value less than 1.0 for sounds to trigger occasionally.
• Use the "Follow" option in an animation to ensure that sounds follow the position of an actor/creature/NPC.
• Sounds can be attached to bones, which is useful for modeling the sounds of large creatures!
• Adding sounds directly to an animation can be problematic for blended animations (e.g. animations from idle -> walk -> run); a better approach is to fire events at key points in animations so that the events can be handled in Blueprint to provide more sophisticated logic.
• When using a "Line Trace By Channel" action, you can debug the trace with "Draw Debug Type" of "Persistent" to see where the traces were done as the player walks around.
• "Project Settings" -> "Physics" -> "Physical Surface" controls the available types of physical materials in the game.
• The "Details" panel of a static mesh allows you to control which physical material a given mesh has. It can be overridden on a per-actor basis.
• Landscape layers can also have a different physical material attached to them, so if a landscape has grass lowlands and hard, rocky highlands, the correct material type is reported for things like collisions and footsteps.
• Non-GPU sprites in particle systems support events, which can be used to fire off sounds.
• "Collision" events on particle systems can be used to play sounds when particles hit other objects. When combined with a physical material check, the sound can vary based on what type of material the particle collided with!
• Particle systems default to not running when the player is not looking at them, which can be problematic for particles that make noise. This can be controlled by making the bounding box of the particle system relative so it's not dependent on the camera/viewport. Match the bounding box to the attenuation to improve performance.
• Reduce the frequency of sound events from particle systems to avoid using up your voice channels.
• The "Vector Length" of the "Normal Impulse" parameter of a hit event measures the magnitude of force applied at the point of collision for any actor.
• The "AudioSoloSoundClass" console command can be used to isolate instances of a specific sound.
• "Debug" can be set to "True" on individual sounds so that isolated sounds trigger debug output when the appropriate console debug mode is enabled.
• When adding sounds to an actor for rolling or scraping, be sure to add logic to check for when the actor is no longer overlapping the ground to prevent the actor from unexpectedly playing these sounds while in mid-air.