Pros and Cons of Unreal Blueprints
Recently, I began exploring the visual scripting system of Unreal Engine, Blueprints, and I've gathered some early insights that might help others who are considering this transition. Here’s a breakdown of the pros and cons I've encountered, along with some general thoughts on using Blueprints in application development.
Pros of Using Blueprints
Ease of Getting Started
The first thing I noticed with Blueprints is how straightforward it is to dive right in. The node-based system is intuitive, especially for those who might not be proficient in traditional coding and the ease-of-use makes it quite fun to just play around with, trying different things. The nodes are intuitively named, different outputs and inputs are color coded by variable type to show what’s compatible and where conversions or casting might be required.
Discoverability of Features
Without sifting through extensive documentation, I could easily discover a bunch of Unreal Engine's pre-built functionalities thanks to the node creation/search function in Blueprints, which is very helpful for discovering and using various engine features (of which there are many, it has been a joy to notice that many standard tools you would often use in 3D games and applications are already there)
Visual Conceptualization
Certain aspects of game mechanics are more naturally grasped in a visual format. For example, setting up timed sequences, particle systems and animations can be more intuitive in Blueprints than coding them by hand. Visual scripting allows you to see the flow of actions and events clearly, and you can look at the flow of the Blueprint nodes while you are running the application which is a n easy way of visually debugging them.
Below you can see a simple timed sequence of the time of day changing and how its flow is visualized in the Blueprint
Component Accessibility
Blueprints provide straightforward access to in-game components. It’s very simple to add these components to your blueprints and for example hook into their events, which makes for a pleasant workflow - adding components and directly using them afterwards.
Here is a video of adding a collider component to a Blueprint and accessing its OnComponentHit event.
Cons of Using Blueprints
Traceability
One hurdle I faced is the traceability of logic across multiple Blueprints, at least during my time with them I couldn’t find an easy way of doing it. Maybe there are tools for this that I didn’t discover, and if not, of course a developer/team can set up and follow strict conventions that trivialize this issue.
Refactoring and Modifications
As projects grow, refactoring becomes crucial. However, in Blueprints, refactoring can be cumbersome as it often requires "physically" moving nodes around to make space for new logic. This can be cumbersome compared to just pressing enter and writing a new line of code.
Below you can see the addition of a simple debug log, let’s just move this other stuff out of the way first…
Third-Party Libraries
Another limitation is the apparent difficulty (or impossibility, not entirely sure yet) in integrating third-party libraries with Blueprints. My impression is that if you have some libraries you want to utilize you’re forced to dive into the C++ side of things
Complexity in Simplicity
Ironically, while certain things can be easier to read in a visual format like this, often simple logic that’s compact in traditional code can become sprawling chains of nodes in Blueprints. Here is some basic initialization logic where I’m storing the reference to a couple of variables and setting up subscribers for a couple of events.
It’s not exactly hard to follow, but if you want to actually be able to read the nodes you’ll have to zoom in closer and drag the view around in order to see everything, while in traditional code all of this would easily fit on your screen at the same time.
Logical Layout
Maintaining a logical and clean layout in Blueprints requires conscious effort. Of course the same can be said for traditional programming as well, but I’m not sure if tested, tried and true conventions yet exist for these types of visual scripting systems like they do for traditional code, and many IDEs have some sort of an automated formatting tool where you can fix the general problems (brackets on wrong lines, missing/additional spaces, indentation etc). Furthermore even if a developer established a strict, specific convention for how the nodes should be organized, having to reorganize them every time you refactor the code must be a hassle.
Lack of encapsulation
Blueprints seem to lack means for forcing encapsulation, such as using namespaces. It seems that at least by default, everything that’s in any Blueprint lives within the same “namespace” as any other Blueprint, so if you want to avoid ending up with a bunch of circular dependencies you again require strict conventions for doing so, instead of having tools/systems helping you do it.
General Thoughts on Using Blueprints
Blueprints seem like a good fit for prototyping and for designers or other non-coding team members to contribute to the development process. For example, they can prepare visual elements with their animations set up in the blueprints and, voilá, they’re ready for the programmer to hook them up to the code.
For larger, more complex applications, however, integrating traditional coding with Blueprints seems like the more robust way to go. Utilizing C++ for core logic and Blueprints for component-specific tasks like UI and animations can leverage the strengths of both approaches.
Despite some of its drawbacks, Blueprints is a sophisticated system that seems smartly integrated with the C++ programming and the rest of the engine. This compatibility suggests that Unreal Engine has been thoughtfully designed to cater to both beginners and advanced users, allowing the Blueprints to be used as an initial learning tool that still doesn’t seem to lose its purpose once you progress past the beginner stage.