Limitations of Blueprint
“The Blueprints Visual Scripting system in Unreal Engine is a complete gameplay scripting system based on the concept of using a node-based interface to create gameplay elements from within Unreal Editor. This system is extremely flexible and powerful as it provides the ability for designers to use virtually the full range of concepts and tools generally only available to programmers.”
The blueprint system is built around nodes of C++ code that you can visually link together to produce scripted results. As a result of being a stage between the engine and the C++ code itself, blueprints based script runs around 10 times slower than if the same thing was written directly in C++. But, it gives people like myself a gateway to creating tools and events in the engine that wouldn’t have previously been able without learning C++ from scratch.
Given that you are using nodes of C++ that someone at EPIC has constructed you don’t have full flexibility with how you manipulate the script. You have to just work with what you are given. I have come across this recently when trying to get a blueprint actor to place another blueprint actor in the level. It is possible to get blueprints to place meshes, but the functionally of placing another blueprint isn’t implemented yet and would require knowledge of C++ and implementing it myself to get it working. I have seen examples of this being done in the Unreal Community but none without the use of C++.
Another issue I have recently found is when trying to organise the variables I have exposed in the blueprint. Normally it wouldn’t be an issue what exact order the variables are in but as I’m making tools for anyone to use I wanted to make sure they are as straight forward and easy to use as possible. To increase the ease of use I have grouped the variables in categories, each relating to the separate functionality’s available in that blueprint. Within the blueprint itself I am then able to order the categories in an order that makes best sense when using the tool. Unfortunately the order in which I place the categories in the blueprint doesn’t mirror over to how they are displayed in the details panel for the blueprint actor (the details panel being the way the user interacts with the tool).
Again this is an issue produced by the limitations of the system and is completely out of my hands to changing. Don’t get me wrong without this system I would have to learn a whole programming language before getting even close to creating what I have. But it is obvious when pushing the system that there are limitations, which has lead me to having to be creative with my solutions and find ways to work around the issues.
This does however have a knock on effect. Working around issues like these tends to mean adding addition script that you previously wouldn’t have to to get required results and as I previously mentioned blueprint is around 10x slower to execute than straight C++ code. Meaning that I have started to notice that some of the tools can be slow to react to changes when working with them which from a usability point of view is less than ideal. I am going to defiantly have to allocate time towards the end of the project to back in and optimise the script as much as possible and add catches to stop sections of script from executing when they’re not needed. Doing this alongside having clear user instructions on the best way to use the tools should result in a good user experience and produce the results from the tools that I am looking for.
