Blueprints Are Code

One of Unreal Engine 4’s biggest strengths is its visual Blueprint system, which allows developers to create entire games without touching a single line of code. The interface is slick, the results can be seen and iterated on quickly, and it’s fairly easy for just about anybody to dive in and start making changes or new features.

All of this power comes at a cost, however. Just as undisciplined software engineers can develop bad habits and negative patterns in the writing of their code, so too can Blueprinters (Blinters?). And that’s because Blueprints are code* and should be treated the same way.

No professional would write code that looks like this:

void ReversifierEXTREME(char* fullString, int startIdx, int endIdexx)
{if (startIdx < 0)
		startIdx = 0; }
	const int length = strlen(fullString); if (endIdexx > length)
endIdexx = length;

	while(endIdexx>		startIdx)

char temp = fullString[ endIdexx];
		fullString[endIdexx    ] = fullString   [startIdx]; fullString[startIdx] = temp;


So why should Blueprints created by professionals be any different?


Even the simplest logic can become a tangled mess without the proper discipline, which is why having a set of Blueprint Standards is important. Applying our current Blueprint Standards to the above Blueprint turned it into this:

After applying our Blueprint Standards

Blueprint Standards

Any team working in Blueprints should create a documented set of standards to use for working with Blueprints. This document should address almost all of the same topics that one would cover in a Coding Standards document: Naming conventions for variables and functions, formatting, usage of language-specific paradigms, etc. and just like a Coding Standards document, the Blueprint Standards should be a living document that is maintained by one or more members of your team.

So what should the Blueprint Standards contain? Well, that’s up to you and your team. On previous projects, we had separate Standards depending on the type of Blueprint we were dealing with (UMG Blueprints, Level Blueprints, Actor Blueprints, etc.) and we also separated the Standards into two sections: “Standards” and “Guidelines”. The main difference between the standards and the guidelines is that failing to follow anything listed under the “Standards” automatically failed Blueprint Reviews (more on that below), whereas “Guidelines” were a set of agreed-upon best practices that we allowed a bit more flexibility on when it came to the reviews.

Here are just some of the topics that we covered in our Blueprint Standards document:

  • Naming conventions for variables, functions, types (classes, interfaces, enums, structs, etc.)
  • Maximum number of nodes allowed before the graph must be collapsed or broken into one or more macros or functions
  • Usage of comments as well as the coloring that should be used
  • How to comment and document “hacks” for easy visibility and tracking
  • How to make “early-outs” easily visible
  • Maximum number of connectors allowed to a single Object reference before it had to be made into a variable

Again, these were just some of the things we covered in our standards, but you should create your own based on the requirements of your particular project.

Blueprint Reviews

Once a set of Blueprint Standards has been created, the team needs a way to ensure they’re being followed. While some of the Blueprint Standards could be enforced at build-time with some well-written tools, many of the Standards will require a human eye to check. To handle this, some companies require over-the-shoulder reviews, while others prefer to make use of the Blueprint Diffing Tool. Either solution works so ultimately it’s up to the team to decide how they would like to handle it.

Why This Is Important

Having a set of Blueprint Standards is important for all of the same reasons that having Coding Standards is important:

  • If the standards are followed, the Blueprints will be more readable by every member of the team since they will have a similar look and feel
  • Having a solid set of standards (and/or guidelines) and performing reviews against them allows bugs to be caught before they enter your project
  • Cleaner Blueprints make it a lot easier to track down bugs that didn’t get caught during the review process
  • Unlike code, Blueprints can’t easily be merged, so even the simplest changes like aligning nodes can cause pain for larger teams
  • Most importantly, because you don’t want your Blueprints showing up here:


Blueprints are an inevitability on any UE4 project and similarly to code, they are likely to contain bugs that will need to get fixed at some point during the project. Just like defects in code, the longer a bug sits and festers in a Blueprint, the harder it becomes to find and fix. Creating your Blueprints in a smart way from the beginning of your project is the best way to minimize issues that can arise and compound as your project moves through development towards the finish line.


* Much of the code that runs behind the scenes to interpret the Blueprints at run-time is very similar (if not identical) to the run-time code used in Unreal Engine 3 for interpreting the UnrealScript language that shipped with the engine. UnrealScript is a language similar to Java, but with constructs that made it more specific to games and the Unreal Engine in particular. So quite literally, “Blueprints are code”.