Unreal Engine: Pickups

Many types of games have pickups. From 2D scrollers to 3D shooters, pick up items are anything the player can pickup in the game to add some ability or resource that they need. In Unreal there are several ways to make pickups, and there are several types you can make. For the purpose of this post I will be focusing on a traditional pickup type where the player picks up the item by crossing over it.

New Class

I am going to assume that you will want to make several pickups for your game and that the pickups will all be the same type as described above. To start will create a base class of which the actual pickup items will be a child class.

In the Content Browser click Add New and then select Blueprint Class. From the Pick Parent Class window select Actor. Once it is added give it name; I called mine Pickup_Base.

Once it is created, double-click it to open the blueprint. We will need to make some additions. First click Add New Component and add a Static Mesh and give it a name; I called mine PickupMesh. Next add a new variable and change the type to Static Mesh. Make it editable and give it a name; this one I called PickupMeshToDisplay. This will basically allow us to use different meshes for different pickup items even though they are from the same parent class.

Lastly click the Construction Script tab. From the Construction Script node drag a connector and type Set Static Mesh. From the left side drag the PickupMesh into the window, and connect it to the Target connector of Set Static Mesh. Then from the left drag PickupMeshToDisplay into the window, chose Get when presented with the options and connect to the New Mesh connector of Set Static Mesh.

 

Pickup Base Construction Script

Child Classes and Collisions

From here you will create the actual pickup items as child classes of the Pickup Base. In the Content Browser simply right-click the base call and select Create Child Blueprint Class and give it a name. Repeat for as many pickup items you are going to create.

For each of the items you will choose a static mesh that you have either created or acquired. If you open the blueprint for any of the child items, you will see that PickupMesh is inherited from the parent. Simply highlight it and select the appropriate mesh.

As mentioned before, these pickups will be traditional and disappear once the player crosses over them. In order to accommodate that we will add a box collision to the child class. Once the box collision is created you can create a simple EventBeginOverLap event to destroy the pickup once it collides with the player

Pickup Events

The event graphs will vary from pickup to pickup and game to game. Perhaps the pickup will add health, or some resource the player needs. Or perhaps the pickup give the player a new ability, either permanently or for a period of time. The possibilities are far too endless to go into every scenario in this post. But any logic for what the pickup will do will be created in the Event Graph of the pickup blueprint. 

As an example I am providing the blueprint below that adds Health to the player character and then destroys the pickup item. This is all done from an EventBeginOverLap event on the box collision of the pickup item.

Pickup Event

This is one simple example of what you can do with pickups. I hope you enjoyed this post and experiment with creating some of your own.

Thanks for reading and see you next time.

- End of Line

Unreal Engine: Creating a Render Farm with Swarm

For those of you who have ever created a large level in Unreal, or at the very least a level with a lot of lighting sources you know that rendering lighting can take quite a bit of time when you do a build. This may also be the case when your PC or laptop is more mid-range than high-end. Speaking for myself I tend to perform a lighting build quite often when I am designing a level and I am placing light sources. I like to know right away how the lighting is going to look when its fully rendered. This tends to be more tedious when designing an indoor level, though I am speaking only from personal experience. So the question then, how to speed up rendering?

The easy answer is to build a better PC with the latest gen processor and as many cores as you can pack into it. Simple enough solution, but not viable for everyone, especially when you are on a budget. So what other options are there?

Enter the Swarm

Unreal Engine has a nice little feature built into it called Swarm. You may have noticed it pop-up in your system tray when you perform a build on your level in Unreal Engine. This is assuming your are designing on a Windows PC, as Swarm currently only runs on Windows. Unreal Lightmass is the high-quality, static global illumination solver that is built into Unreal Engine. Every time you do a lighting build on your level Lightmass is what is crunching the numbers. If your level is large or complex this can be very processor intensive, even on an 8-core system. Swarm is an agent for Lightmass that allows you to distribute light rendering jobs across multiple Windows PCs; split the load across as many processors as possible to shorten the time required to build lighting. It essentially works like any other distributed computing program, such as SETI@home or folding@home, or many other projects you may have contributed spare CPU cycles to. Most big studios pushing out triple A titles will have entire racks of servers dedicated to Lightmass rendering. 

Lets Start Farming

So if you are a nerd like me, you probably have some extra PCs lying around. Maybe from your last gaming rig, or something you cobbled together from spare parts. Lets assume that you do. In my case I have two small servers and some workstations at my repair shop that are usually not under heavy load. Working six days a week, I tend design levels for my 3D design class during slow points of the day. So I have Unreal Engine installed on my primary workstation at the shop.

Setting up a render farm is actually quite simple. A few things to note to begin:

- You do NOT need to install Unreal Engine on PCs you want to run the Swarm agent on
- You will require the latest version of .NET framework
- You should install Unreal Engine Prerequisites on Swarm PCs
- As previously mentioned, Swarm only runs on Windows currently
- Swarm uses CPU for rendering, not GPU
- There are two components to Swarm, the Agents and the Coordinator
- Swarm PCs must be on the same physical network, with Gigabit speed preferred

So for my specific example I will be running the Swarm agent on my main workstation, and two servers. I will be using a second workstation as the Coordinator. Between my workstation and the two servers I will have 24 processor cores available for rendering. The Coordinator does not perform any rendering, it merely coordinates the jobs and distributes them to the agent PCs. Typically in a rendering farm you will use the least powerful system you have as the Coordinator.

Running Swarm

Whether the system is the Coordinator or an Agent, the installation process is the same. I always begin with installing Unreal Engine Prerequisites on the Swarm systems. You can find the prerequisite installer on the system you have the full Unreal Engine installed on in the following folder:

C:\Program Files\Epic Games\UE_4.14\Engine\Extras\Redist\en-us\

The UE_ folder will vary depending on the version of Unreal Engine you have installed. You will see two files:

UE4PrereqSetup_x64.exe
UE4PrereqSetup_x86.exe

Since all my Swarm systems are 64-bit I will copy the 
UE4PrereqSetup_x64.exe file and run it on all of them. If your systems have 32-bit Windows installed, run the UE4PrereqSetup_x86.exe file. This ensures that you have the correct runtime libraries that Swarm needs.

For the actual Swarm files you will copy the DotNET folder from Unreal Engine to the Swarm systems. You can find it here:

C:\Program Files\Epic Games\UE_4.14\Engine\Binaries\DotNET

Copy the entire DotNet folder. I typically will manually create the following folder structure on the Swarm systems:

C:\Program Files\Unreal Engine\4.0\Engine\Binaries

And then I will copy the entire DotNET folder into the Binaries folder. To run Swarm just double-click the executable in the DotNET folder. We will start with the Coordinator. On the Coordinator system you will run the SwarmCoordinator.exe file. Once you run it you will see the Coordinator window pop-up on screen.

Swarm Coordinator

Until we run and configure the Swarm Agents, you will not see much in this window. At this point though, make note of the IP address and Name of the Coordinator system. We will need it when configuring the Agents. Please note that the Coordinator does create a System Tray icon. You will need to keep the window open for the Coordinator to be running; you may minimize the window, just don't close it.

On the Agent systems run the SwarmAgent.exe file. You will not get a pop-up window this time, just a System Tray icon on the lower right corner of your screen. Double-clicking the tray icon will open up the Swarm Agent window.

Swarm Agent

You will need to do just a little configuration on the Agent. Click the Settings tab on the Agent window. You will modify two fields.

Click the AllowRemoteAgentGrooup line and make the following edit in the right pane:

Default

You want to make certain that the AgentGroupName and AllowedRemoteAgentGroup are identical on all of the Agent machines.

Next click on the CoordinatorRemotingHost line and type the Windows name of the Coordinator system in the right pane. For example if the PC running the Swarm Coordinator is named PC1, type PC1.

Swarm Agent Settings

Once you have made the changes you will need to restart the Swarm Agent on the system. Repeat this step for each of the systems you will be running the Agent on. You will want to do this on your system with Unreal Engine installed as well. Once the Agents have been configured and restarted, you see them populated in the Coordinator window.

Coordinator with Agents

As you can see in the image above, our Coordinator now has Agents available to assign rendering jobs to. We are now ready to farm. I did find that you will want to close the Swarm Agent on the system where you are running Unreal. If the Swarm Agent is already running on that system you will get an error when you try to do a Build, as it automatically tries to start the Swarm Agent. 

Performance

As a test I am going to perform a build on a level for a group project for my 3D Design class. It is a large outdoor level with structures throughout the level. I will run it once without the Coordinator distributing the job, and then again with the build distributed.

Non-Distributed Build Time: 3 Minutes 5 Seconds
Distributed Build Time:     1 Minute 16 Seconds

As you can see, a marked improvement with a reduction of 59% in build time. If you want to check the status of your distributed job simply double-click the Swarm Agent icon in the system tray to bring up the window and click the Swarm Status tab.

Swarm Status

You may notice from my screenshot that actually only one of the Swarm Agents was contributing to the job. The middle agent was producing an error which I will need to troubleshoot. But even with only a single extra Swarm Agent helping with the workload, the build time was reduced by more than half. 

I will admit that the level I chose to build was not terribly complex. However, this test still demonstrates how distributing Lightmass jobs can dramatically reduce build time.

As always I really hope you enjoyed this post and found it informative. I know I enjoyed the exercise of creating a render farm. Until the next post.

- End of Line