It doesn’t look like AsyncTask is exposed to BP and the only solutions I’m finding are marketplace plugins. Has anyone had any success pushing tasks to a separate thread in BP?
The blueprint interpreter VM is not thread safe, and must run on the main thread.
If you have anything that is performance intensive (and thus will benefit from threaded execution) it should not be implemented in blueprint anyway.
Blueprint is for wiring up and configuring objects, not for running heavy game logic.
Ok, then what about plugins like the following?
I’m trying to better understand how these work. You very much can multi-thread from BP. I’m just trying to understand better how.
Blueprint is for wiring up and configuring objects, not for running heavy game logic.
I don’t agree at all.
TL;DR at the bottom but I would still recommend you read through all of this.
Off the bat: I’m not an expert and don’t know much about these plugins but I’m willing to make some assumptions that I think would be safe to make.
Those I think are very highly specialized plugins, with hacky solutions to work around that. They’re most likely written in C++ and implement their own solutions for working around single-thread limitations.
Again, I don’t really know how these work all too well. You’d have to decompile them and look at the source code, and that’s really not something I think you can do, especially not without the seller’s permission.
So here’s the thing about Blueprints and heavy logic.
TECHNICALLY, yes, you can use Blueprints for heavier game logic. I used to do it all the time. One of the first versions of a gameplay framework plugin I’m developing was entirely written in Blueprints. I recall that it made heavy use of delegates (good) and nested structs (not good, but back then I had no idea what I was doing lol). It ran… fine. Didn’t hitch or anything, and on Unreal 4, making basic little levels to test it out and try building games with it, well, it did the job just fine. DIdn’t have any framerate issues. I scrapped it later because it wasn’t flexible enough… too hard-coded and thus too difficult to update or expand for other games in the franchise.
REALLY, though, you may (or may not) want to avoid that for a few reasons. I won’t tell you what to do with your project, because it’s your project and not mine. However, I will still present a couple of points from my experience. These two are the main reasons I mostly work in C++ nowadays (even though I was terrified of it not even a year ago). I still use Blueprints plenty (widgets and scripted events without them are a nightmare), but I did come to a similar conclusion to what jwatte has stated for these reasons (though, he is an engine contributor and would definitely know more than I do).
Performance.
Blueprints have to run in the Script VM, which adds overhead. In smaller scripts and basic stuff that won’t matter at all. Once you get to running bigger and bigger functions, especially running them often (like on a Tick), that overhead will start to add up. If you have a LOT of objects doing these kinds of heavy loads, that overhead will add up lightning fast.
One one hand, I couldn’t emphasize how much smoother some functions have gotten for me just by moving them to C++ (like player movement). On the other, moving some functions to C++ didn’t make much of a difference.
Stability.
This seems to be hit-or-miss - some people have problems and others don’t - but I definitely remember having a lot of stability issues with Blueprints in some of my projects. Mostly data corruption ones, especially. Granted, this was usually from having a lot of nested structs (a bad practice anyway, or so I’m told), and having a lot of structs in general as well. That, and on Unreal 4 they didn’t seem to be too bad, just on Unreal 5 (especially Early Access, in those days even a tiny unnested Struct would crash the engine if I looked at it sideways).
If you would like more resources regarding this Alex Forsythe made a great video on it which I recommend anyone using Unreal to watch: https://www.youtube.com/watch?v=VMZftEVDuCE
So, that’s my two cents on this.
TL;DR: Those plugins use their own hacky workarounds to the Blueprint script VM’s single-threaded limitation (and may be a little unstasble but I couldn’t tell you), and there are a few reasons you wouldn’t want to use Blueprints for heavy game logic, namely stability and large-scale performance.
1 Like
I’m aware there’s performance limitations in BP, but I’m not hitting them as I’ve started out of the gate with modern coding practices applied to BP and understanding the limits of BP. The only performance issues I’ve hit with BP are itinerating over a large array, which I’ve moved to C++ to resolve. I don’t use BP Tick as it’s terrible. Everything is timer based if some form of timing is needed. There are no delays to cause GameThread to pause. Entire game is event and data driven.
Can’t say I’ve had any stability problems though. I had no issue moving to UE4 > UE5 > UE5.1, but as you said this is a hit or miss and probably has something to do with how BP is being utilized by some.
I’ve already seen the video and agree everyone should watch it as it’s absolutely fantastic. I’ve taken several ideas from it. Basically profiling, finding high cost functions, and refactoring them into C++ if needed.
This is honestly just a curiosity thing more than “I need this!”. I’m well capable of writing C++. I just don’t want to. My day job is being a programmer. I find BP a refreshing break from code and gives me a new way to think.
1 Like
Reasonable! If programming was my day job I’d probably want a break from it at home too. And a little curiosity (usually) never hurts.
You may be able to message the developer of one of those plugins and ask them how it works in detail. I’m no wizard and I definitely don’t know how you’d pull this off, but my best guess is that they probably use custom nodes written in C++ to tell the engine to fire X code on a different thread, effectively bypassing the main thread limitation. Again, though, I’m not an expert.
They may not want to give away their secret either since it’s (supposed to be) making them money. Maybe one of them would be nice enough though.
And yeah I agree, I avoid tick and excessively large arrays in Blueprints too. Stability is def a utilization thing, honestly if you aren’t nesting a bunch of structs and being careless with hot-reload you’re probably safe. Seems your use case is being plenty gentle with the VM so you’re definitely fine.
1 Like
Well, technically, “asynchronous” just means “deferred execution,” and can still happen on the main thread.
As it turns out, you can already do this in regular blueprints; just make an event out of a function on your object, and bind it to a timer! The timer could be set to execute 0 seconds in the future if you want.
Multi-threading blueprints for real (running multiple separate blueprint functions in parallel) and even just calling into the Unreal gameplay framework in multiple threads, isn’t supported. It might maybe be possible to create a whole second instantiation of the blueprint VM, and run a second set of blueprints there, but then they’d have to use some kind of message queue to pass data back and forth, and they couldn’t be using the same objects. Also, you couldn’t really use all of the Actor stuff from more than the “main” instance.
Finally, plugins in the store generally come with source, so you could buy them and see how they do it. Maybe there’s something really clever there that I don’t know about? I would probably bet against that, but the chance is greater than zero 
1 Like
Yeah that’s what I wasn’t sure about in regards to these plugins. I know you can make AsyncTask calls in C++ on separate threads. The plugins do imply they’re doing this.
Yup, already doing this basically. I’m using nearly entirely event driven gameplay. Basically I don’t have any heavy blocking operations. Probably my heaviest operation is my projectile logic since they can bounce, pierce, fork, chain, etc…
Very interesting! Thank you! That would be wild to run a second instance of the VM lol, but I guess that’d really only be useful to optimize heavy itinerations, which is easier to just throw into C++ lol.
I think I’ll do that and see what is going on. Wonder if Unreal plans to support multithreaded BP in the future.