Working in Unreal Engine

For any developer there is a wealth of options out there for out-of-the-box solutions. In the triple-I spheres the choice seems to be Unity or Unreal and both certainly have their detractors and supporters. Personally, I chose Unreal because it gels with me and I like BluePrint visual scripting. It may not be the right fit for you or your project, but it’s free to try out so you might as well give it a gander. Here are a few working tips I’ve gathered for developing in Unreal.

Learn shortcuts

UE4’s contextual right-click pop-up menu is powerful, as is its quick-search feature within those menus. But nothing speeds up your workflow as knowing the shortcuts for your most common used nodes. E.g. holding B and clicking to create a “if (branch)” node in BPs, L for a lerp node or 1, 2 or 3 for scalar or vector nodes, everything flows much faster that way.

Organise, but don’t go overboard

Keeping clean BluePrints is important. UE4 even has align and straighten connection features to help you keep your project off the pages of Blueprint from Hell. But it’s easy to go mad at organising them. As long as you keep relevant sections within comment boxes, use reroute nodes here and there so the flow remains visible you’re golden. Collapse nodes that are growing out of control, replace sections with functions. Keep it readable. In fact, I found the cleaner the BluePrint the less inclined I became at fiddling around in them.

Use comments and colours

Following on from the above, extensive commenting in BluePrints is where I eventually landed. Keeping selected nodes together in a comment box (shortcut: C), naming them intuitively, and colour coding them as I went along seemed to work for me. I stuck with a few rules, like bright pink for temporary debug nodes, deep red for unhooked nodes that probably needed deleting at some point and green for “finished” segments. When opening any BP this allowed me at a glance to see its status.

There is another little trick I use to keep local notes I need to refer to often. Rather than having to refer to documentation every time I need to reference a, say, array’s indexes I sometimes make a reroute node, click the little comment bubble, add my notes, and then pin that bubble. This means I can continue working within the BP without having to tab out to documentation for lookups.

Use source control

Not a UE4 tip per se but a general game development tip. Use source control! There are plenty of solutions out there, some free, some not, but developing without source control is like free climbing. Sure, you may not have needed ropes, but when you do it’s better to have ropes than not.
Personally I use Github but there are many solutions available that suit your needs and wants. On top of this, make regular backups!

Don’t sweat the 5%

One of the main reasons detractors of UE4 usually throw up in arguments is the “Epic tax” of paying 5% of royalties if your game sells over a certain threshold. “Why should I just give Epic my hard earned cash?” they lament. In my case that 5% is still way cheaper than the overheads paid on a team of coders and tool programmers that would take UE4’s place. If your coding team takes less than 5% of your development budget I’d be amazed. Plus, perhaps the outrage is better spent on the 30% the platform holders take, which nobody seems to have an issue with. Sure, if you sell billions of units that 5% can rack up, but…let’s face it, you’re not going to sell a billion units.

Use the engine as much as you can

You may have heard of the “not coded here” syndrome where developers feel the need to roll their own solutions rather than spend 5 minutes reading some documentation on existing solutions. UE4 allows for custom engine tweaks and plugins, but also be aware that those aren’t always necessary. The more you can do within the framework of the engine the easier it will be to follow Epic’s own periodic engine updates. Do the research, read the documentation, see how Unreal does things before writing your own code.

Keep a junk project

Keep a junk project lying around for little tests and experiments, or even little bits of script that work great but aren’t a good fit for your project. Whenever you think of that one cool thing you did before you want to copy you don’t have to trawl through numerous older projects, just your one “sketchbook” project.

Drag temporary nodes off of loops

This is a lifesaver for me. If you’re using ForEach loops, or loops of any kind, whether they are followed by more nodes or not, always drag a reroute node off the “complete” output. It is so easy to forget this output and put general nodes within the loop, rather than after it. When you revisit a BP and see that empty reroute node it’ll help you jog your memory to not add any new functionality within the loop but after it.

Avoid making localisable variables in BluePrints

If you’re planning on using UE4’s localisation dashboard, avoid writing localisable texts within your BPs; instead always make variables that are referred to in your BP or the localisation dashboard sweep for text might miss them.

Make functions for oft-repeated actions

There are things you’ll do often in your project, like save gamedata, check on certain variables, etc. For most you’ll end up creating a function you can call on at any point. But also consider creating functions for smaller tasks that you often rely on. It helps keep your BPs readable and clean, and can make your life so much easier.

Make builds regularly

And I mean, regularly! At least once a week, if not more. Do a build, test our game on the target hardware. Even if you’re just adding content, rather than functionality, test, test, TEST! When things go wrong, as they are wont to do, you’re only looking at a week or a few days’ work to trawl through. With this and good source control you’ll hunt down and fix issues fairly quickly.

Deal with warnings!

When you open a project, check the log. When you play the project, check the log. When editing check compiler results. Whenever a warning pops up, deal with it immediately. I have made it a matter of personal pride to never commit (at least to the main branch) my project unless it is warning free. Whenever I open my project, no warnings. In game development it is often difficult to prioritise your work and to put off until later important things because you’re focused on something else. But to keep a clean, working project at all times is something I prioritise.


It is always a good idea to follow tutorials. If you need a break, or are having a cuppa, or some lunch, why not browse the Epic YouTube channel and look at a few of their videos? If you’re planning to tackle a specific subject, why not Google a few tutorials on that first? There is so much information out there that there’s a good chance someone has already solved a problem you’re facing. Sometimes, even, someone will show you a more efficient way of something you’ve been doing already. Information is power!

Disclaimer: Other than the contractual obligations I fulfil as a user of the Unreal Engine I have no other affiliation with Epic and have not been paid to promote or write about UE4. That said, if Epic wants to get in touch… 😉

One thought on “Working in Unreal Engine

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s