Now that my blueprints are getting bigger and bigger, I am starting to think whether it will be better for the in-game performance, response times etc. to have
(1) as much information stored in one class blueprint as possible
(2) equally divide logic between many small blueprints which keep casting to each other.
I dont mind the compiling times that much, but if I keep on my current route of (1), setting most of major things in one main blueprint (MyCharacter),
will I get reduced performance in the game…?
I would expect casting from actors to actors more heavy on performance than having a big one, but I am not a programmer so I might be on very wrong tracks here.
For example, is it more expensive to cast to a blueprint that is huge than to a small one? Will my MyCharacter become a performance bottleneck if I make everything cast to him
all the time?
I suppose it is also a case-by-case situation, but I have to set my general guideline to one path to maintain smooth progress.
Amount of nodes per blueprint does not directly affect in-game performance. Casting is rather slow in UE4 so do it once if needed but don’t abuse. If you want your blueprints/code to be clean, follow object-oriented programming paradigms. In character blueprint put only logic related directly to his behavior. Use inheritance a lot (where its appropriate of course) instead of get all actor of class nodes. Store data/logic related to one object in one class. Put getters/setters in classes to modify internal values instead of modifing externals. Avoid using event tick too much… etc
Other than cleaning/organization what you are worrying about is premature optimization; write your game and profile it when it becomes slow or exhibits poor performance. Always pick the lowest hanging fruit; you could spend days making your BPs and files “pretty” and just make things worse.
My motto is:
Make it work
Make it work well
Make it look good
Do not move forward until you can happily “check off” each step; no one that will play your game cares about your timely cleaned BP node styling.
I am very much going to disagree with this statement; inheritance is a terrible thing when used incorrectly, use components and interfaces over inheritance as much as possible. Additionally, get all actors of class has a bad comment “This is a slow operation…”; slow is a relative term here, if you have dozens or hundreds of actors in your game, do you really care if enumerating them takes nano seconds?
Slow is only slow when its not fast enough, and if you spend time “speeding up” something that’s fast enough, you are again wasting time on things people don’t pay for.
Anything can be “terrible thing” when used incorrectly. Components and interfaces does not exclude inheritance. Get all actors of class is slow and cumbersome solution in most cases, mainly (as you mentioned) because it enumerates lots of unneccessary stuff.
Not attacking you, but you are a just further making my point; “lots of unnecessary stuff” is relative not absolute. If “lots” is hundreds or even thousands and does not impact your performance then enumerating them is harmless (and changing working code for the sake of changing it is wasteful).
The next time you see someone selling a game and one of the bullet points is “clean looking optimized code that does not enumerate lots of stuff”, let me know.
Yeah, thanks. I get the idea and agree with it.
I just wanted to be premature a bit because, if there is a “right” way of doing something I should start practicing it rather now than later and be forced to redo everything.
I dont mind practicing and improving, but I would still wish not to do any fundamentally wrong choices for the whole pipeline.
For example, I am not there yet, but at this rate my MyCharacter blueprint will have 50+ functions and 50+ variables. I can manage it but started to worry if spreading some
of the variables and calculations to other actors would be a better choice.
