Announcement

Collapse
No announcement yet.

For optimization and game response, is it better to have many small blueprints or few large ones?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    For optimization and game response, is it better to have many small blueprints or few large ones?

    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.

    Thanks for any advice!

    #2
    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
    Last edited by Xter; 10-27-2015, 01:21 PM.

    Comment


      #3
      Originally posted by Xter View Post
      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
      Can you use getters/setters in blueprints? I'm familiar with doing that in programming but is there a special blueprint node/process for that?

      edit: actually, it's been a while since I dug that far into programming. so sorry if that was a stupid question. I need a refresher.
      Last edited by 0vr; 10-27-2015, 05:04 PM.

      Comment


        #4
        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:
        1. Make it work
        2. Make it work well
        3. 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.

        Originally posted by Xter View Post
        Use inheritance a lot (where its appropriate of course) instead of get all actor of class nodes.
        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.

        my 2c

        Comment


          #5
          Originally posted by bleeds187 View Post
          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:
          1. Make it work
          2. Make it work well
          3. 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.

          my 2c
          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.

          Comment


            #6
            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.

            Comment


              #7
              Originally posted by bleeds187 View Post
              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:
              1. Make it work
              2. Make it work well
              3. 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.

              my 2c
              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.

              Comment

              Working...
              X