Further tips for working in Unreal Engine 4

Following on from a previous post that gave some tips on working in UE4 I thought I’d expand a little with a few more tips and tricks. Especially with the recent announcement of UE5 and a new royalty scheme, Unreal Engine is looking more and more like the go-to engine for gamedevs! Everybody has their own work style and ways of handling things, so these tips are just what I personally found useful for myself.

Q to straighten connections

Though I’ve previously said not to worry too much about spaghetti in BluePrints, keeping things organised and readable is definitely a plus. If you’re working with other people on a project being able to easily read and understand the flow of your BP is pretty important. As such it helps to spread out your connections into easily readable flows.

One of the biggest annoyances in BPs is that boxes snap to the grid according to their own size, so the connector might be slightly off. The easiest remedy for this is to keep your finger on the “q” button when dragging your nodes. “Q” is the shortcut to straighten connections. This little key will be the, um…key to keeping your BPs clean!

Collapse nodes

Sometimes you don’t need a separate function for something that does however take over a big, ugly chunk of your BP. Say you have a complicated set of calculations for a single instance of something but it takes up half a screen of space with a web of connections. By selecting all the nodes in that area and selecting “collapse nodes” you can put them in a “bucket” to neatly store them away. If you make sure to name the bucket something very obvious the BP remains readable (and editable) without becoming too much of a mess.

No IFs or buts but SELECTs

At it’s most basic “coding” (and therefore scripting) can be described as a series of “if” statements. If your player is there, do this, if they do that, do something else, etc. Down to the smallest calculation it is often down to an “if” branch. However, it is not always the best solution to actually use the “if” node (shortcut “b”). You may forget to connect up the loose ends, you are splitting your BP in two, it can get confusing and laborious.

The “select” node does pretty much the same thing in a much easier to read way (although you can of course go overboard and turn it into a complicated mass as well, if that’s your thing).

Build your materials to be versatile

Every material requires a draw call and every draw call goes towards lowering your performance. These days the platforms we use are fairly powerful, so for simpler games, like my own, there is a long way you have to go before optimising the minutiae. That said, if you try to stick to good practices from the outset you can really help your project.

Relying on material instances rather than a new material for every little thing is one way of doing that. For example, if you have an object that is just a single colour, say red, and one that is blue you don’t make two materials, you make one with a colour parameter and apply an instance of it to both objects, tweaking that parameter on each.

Generally I tend to group my materials by the function they serve and add as much in the way of tweakable parameters to each until material complexity starts becoming an issue. Where that border lies is up to you, but as a general rule try sticking to relying more on material instances than materials.

Check for off-the-shelf solutions

Though I wrote previously about the dangers of using custom code and what it does to your ability to easily upgrade your engine version, it must be said that plug-ins can be a real time saver. Chances are, if there is a function you really need that UE4 doesn’t provide someone will have made a plug-in for it already. The Epic Marketplace is a super handy resource for these and often a few bucks for a plug-in can shave weeks off of your task list. It is worth checking out!

That said, always check whether the plug-in is compatible with your current engine version and platform, and check the seller’s history and comments to gauge how likely they are to update their work with newer engine versions. You don’t want to become reliant on a plug-in that is no longer supported, tying you to a lower version of the engine for the entirety of your project!

Use auto-save

I read one “starter’s guide” to UE4 that recommended you turn off auto-save because it was intrusive and annoying. Oh lord do I consider that to be bad advise! You can always cancel an auto-save before it happens because UE4 handily throws up a little warning that it is about to happen. But even then, auto-save has saved my bacon so many times. No matter how well I think the editor is built random crashes happen and work can and will get lost!

If it is too intrusive to you, change the interval at which they happen. If you’re afraid you’re going to save over old work then make sure you are using proper source control. I have mucked things up for myself on occasion and it was always easily fixed by reverting to a previous version of the file using source control. Auto-save is your friend, it is not there to annoy you!

Be prepared for time sinks

Grabbing the engine source, doing a build, either for the first time or a clean rebuild of your entire project, these things take time! And while these things are happening there really isn’t much you can do with your PC in the meantime. Though having a dedicated build machine can be a little prohibitive, consider having at least a second device around for doing other work while your PC is occupied. A laptop to do your emails, a tablet for sketching, anything but sit there and stare at a pot of boiling water.

Reconsider the “Epic tax”

I have always been a supporter of Epic’s royalty set-up, and yet it is the thing I hear most complaints about when talking to other indie devs. What is derisively called “the Epic tax”, a small cut of the royalties after your game sells an X amount has recently been revised to be, in my eyes, even more of a boon. The “X amount” used to be US$3000, a low bar that most developers will pass easily. But back-dated to January of 2020 that bar has been lifted to US$1 million!

This means your average small scale indie developer now has much more room to manoeuvre before that payment kicks in, making it a much more attractive proposition. Of course, every developer believes their amazing game idea will make them multiple millions of dollars overnight, but the reality is that many smaller indie games won’t sell that much. The bar is high enough to eke out a decent living without that “Epic tax” kicking in.

* * *

As always it is important to remember that choosing the right tool for you depends on many things. Not only does it depend on the nature of your project, the platforms you’re aiming for, the make-up of your team, budget and schedule, it also depends on you, the person who has to use it. There is no “correct” or “wrong” choice in this regard. I personally really like UE4 and enjoy working in it very much, but that doesn’t mean it’s the best engine out there for you. It being free to use, with no royalties for earnings below US$1 million does make it a very attractive prospect to at least give it a whirl! Good luck!

Leave a Reply

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

WordPress.com Logo

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

Google photo

You are commenting using your Google 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