Blueprint Optimization

Just wanted to ask someone here who might know.

I haven’t experienced any “real” performance hits from doing things the way I have been. Meaning each actor has it’s own set of code. I generally try to avoid the tick event whenever possible. I’ve been using the engine for a few years now and never really looked into things like this.

What I’m wondering is where the best place to place logic is. For instance, in an FPS game, where the character will have tons of variables and functions, where is the best place to put this logic. Within the character blueprint itself? This is what I’ve always done, but the event graph VERY quickly becomes crowded and full of nodes everywhere. It might not really affect anything, but I was wondering if it’s better to store variables and functions and other things that you don’t need in the character blueprint elsewhere.

I haven’t really done much testing on this but wanted to see if anyone knew if there was a “best practice” for these things, or if keeping everything within the same massive blueprint is ok.

Depending on what the variables are: playerstate might be an option to store values. You can also group variables, so it wont be a big list.

To prevent the graph becoming to big: use Blueprint functions or even blueprint libraries. This makes blueprint code reusable too!

You can also move logic down to a C++ base class and use Blueprints only to script high-level events and parameterize the base class. The main advantage of using C++ in my opinion is that it remains readable far longer than the Event Graph. I’m a professional software developer by day so those that do not have a background in programming might disagree though.

Functions and blueprint libraries would reduce the crowing in the Event Graph and you have the Collapse Graph option aswel. Readability is always good.

As for performance, you might want to check if everything done in the Event Tick is really necessary at each tick, since this might have an impact on your frame times, so the best course of action is to divide the actions there with a sequence node, unplug them and take notes on how much time you are increasing with each action. The second step, would be an analysis to know if you really needs them to happen each tick or if you can execute that action at certain intervals, ie each 100ms or each 200ms, so you can like accumulate on a variable the elapsed time since last tick (you can have several) and once a certain amount is reach you reset the counter and do the action.

Hopefully my explanation makes sense and good luck.