A typical argument I often hear against blueprints is that they are slower/not as performant compared to C++ code. But I was wondering, if you are making a turn based game where the action is not real time does this matter? Note that I am talking about COMPLEX games, where there is A LOT of stuff being calculated whenever the “end turn” button is being pressed. Would the slower speed of blueprints hold such a game back or does it not matter because the game is turn based and doesn’t require a smooth framerate? Or would wait times between turns simply be too long/annoying?
I am toying with the idea of creating a turn based 4x game of sorts, but don’t want to use Unreal’s blueprints if things get too slow using them.
You should not only consider performance but also readability. Calculations in Blueprint turn into spaghetti in no time while it can be a few lines of C++ while the flow of game logic is easy to follow in Blueprint compared to C++.
I suggest you use both for pretty much everything. Make a base C++ class declaring all the variables and assign them in Blueprint and add logic in Blueprint and calculations in C++. Also remember that you can’t make anything truly private in Blueprint so you quickly end up with a Blueprint with a ton of “private” functions exposed that you have to scroll through.
That’s interesting but doesn’t technically tell me what I wanted to know. Yea I understand that the blueprint+C++ combo is strong but I was merely asking if using blueprints harms performance even if the game is turn based.
Even in a turn-based game you probably don’t want the frame-rate to stall once in a while but there is ways around that by hiding the stall with something static, precalculating or staggering the calculations so if you want to do everything in Blueprint you probably can get away with it depending on how demanding the game is.
A decent PC will cope with thousands of simple-ish blueprints ticking / updating every single frame. Heavy end of turn calculations, as long as you’re spreading them out over many ticks, will also be fine, but that rule would also apply to C++.
Don’t use editor performance as a metric either, create a “development” build and measure performance there, in my project blueprints run about 10x better without the editor bogging them down, shipping is even faster.
Personally I like making async / deferred logic code in blueprint, as this type of code is very “graph like”, and blueprints can visualize that really, really good.
I keep most of my data definitions, math and data structure manipulations in C++, because its neater, and you have a lot more power / flexibility with the Reflection system in there. Also working with Arrays, Sets and Maps in blueprints can be full of traps, even for experienced users, in Blueprint.