As a programmer, the first thing I wondered when looking at Unreal and wading through hours of tutorial videos was “where’s the code”? All the examples I was looking at had people creating functionality using blueprint graphs.
These blueprint graphs are surprisingly powerful. The editor is very easy to use, providing a ton of context sensitive help in selection of the nodes and allowing you to quickly wire them up. Designers were jumping in and putting these graphs together and making things happen in the game before we’d started the code to do it. “Oh god”, I thought, “I’m out of a job”.
Opinions were – and still are – divided on the use of blueprint graphs. There is concern that functionality implemented through a graph is considerably more expensive than a C++ alternative. Commonly repeated figures say 10x slower. This wouldn’t surprise me, but reactions on the team vary.
Personally, I think blueprint graphs are fine for implementing limited amounts of functionality. Small, event driven functions can be quickly added. Anything that’s being regularly ticked on multiple objects, or anything that looping over multiple data items, would probably be better implemented in C++. You run the risk of the premature optimization pitfall. Writing a C++ alternative may save a few cycles, but if it’s something that’s only triggered once or twice an hour or typical gameplay, what have you actually saved?
Also, old me pulled faces at the graphs and said we should just be writing code in vi, and get off my lawn. But then old me also saw a few clicks and links in a UI blueprint suddenly produce a functioning pop-up window without a single pair of {}. Others on the team vary from “no blueprint graphs at all” to “ok for prototyping” to “they’re fine”.
Pros:
- Easy to setup.
- Harder to make a mistake. It’s difficult to crash Unreal through a blueprint. You’re less likely to make a typo.
- Designer friendly.
Cons:
- Complex graphs can be difficult to read.
- Difficult to track changes. You can’t diff revisions of a blueprint in standard version control software.
- Difficult to track the code flow. If we’re jumping between C++ code and graphs implemented on an obscure blueprint, it can be difficult to figure out what’s happening where and why.
The issue with diffs is a big one. I’m not sure if there are any tools out there that attempt to compare blueprint graphs and identify the changes. We had a similar issue with Unity’s prefab files, but at least they were text-based, and you could compare the yaml contents to an extent. With so much functionality possible in the blueprint files, the fear is that bugs could get introduced that take longer to figure out because we lose the ability to see what changed.
When you search for information on implementing something in Unreal, the vast majority of what you’ll see is people constructing these graphs. You have to explicitly search for C++ implementations. Is this because graphs are the way to do it, or is because graphs are the quick and simple way to show quick and simple examples? I’d like to peek at the implementation of large triple-A projects that use Unreal to see how much they’ve ended up splitting.
So yeah, I guess we’ll find out as we go along. So far, we have almost exclusively used C++ with a very limited amount of blueprint graph, mainly for UI work. I wouldn’t be surprised if we ended up using more graphs, but for now it seems to be working for us.