Announcement

Collapse
No announcement yet.

it it a good or bad idea to have a hub for inter-BP references?

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

    it it a good or bad idea to have a hub for inter-BP references?

    So i often find that references between blueprints get a bit complicated and was wondering, Is it a good, bad or indifferent idea to have a BP_Hub who's sole purpose is to have a list of references to and from every other blueprint.


    for example;
    BP_playerCharacter, BP_playerController, BP_inventory, BP_pickUps, etc would only have a reference inside of them to BP_Hub. Then BP_Hub would have a reference to each of them in return.

    Then when a reference is needed the Blueprint would request the reference from hub.


    I hope i'm making this clear. I understand this adds a link to the chain but i can't imagine it has a significant effect of performance? and I find it makes things a lot easier to keep organised.

    Just hoping to get some feedback on this method.

    Thanks in advance.

    #2
    am i asking a stupid question here?

    Comment


      #3
      What way are you using to accomplish it without the hub? It just seems like you're adding a step, without simplifying anything.

      Instead of GetOwningPlayer->GetPickupComponent, you'd do GetHub->PickupComponent. Or instead of GetGameMode->Cast to CustomGameMode, you'd do GetHub->GameMode. I just don't conceptually see what you're gaining.

      The downside would be if any of those things aren't supposed to last forever (an individual item like a potion), it'd never be garbage collected, since it's still referenced in the Hub, which could lead to memory leaks. But if you're only using it for permanent things like systems, then that's not an issue, either.

      Comment


        #4
        I don't think it will have a big impact on performance. If it saves you from using a lot of "Get All Actors ..." calls, it might actually improve performance.

        I'd say do what you need to in order to stay organized. Personally I would not find it helpful to have a single "hub" for ALL blueprints, since that seems to me like putting all of your system's files into one folder, but it might be manageable if your game doesn't have a lot of distinct BPs.

        Keep an eye out for circular dependencies, though...if BP_Hub needs a reference to BP_inventory *and* BP_inventory needs a reference to BP_Hub, you can run into issues if things don't happen in the order your planned.

        Comment


          #5
          I typically practice setting the references for game instance, game state, game mode, player controller, and player state on BeginPlay with each actor that will utilize them. Essentially those are the hubs to utilize communication across all blueprint activities unless you use interfaces.

          Comment


            #6
            As BP_Hub has a reference to everything and everything has a reference to the Hub you don't end up with references to references to references. I always know that if i create a reference to the hub blueprint i can access anything from anywhere else in my game.

            I should point out i am by no means a programmer Blueprints is the first coding system that has actually stuck in my head in any way. So "common" coding practices will be completely foreign to me.

            Prior to using the hub I was following tutorials where the interface would have a reference to the controller and another to the inventory system and another to the player.

            I'm a visual person and this is how i see the references with and without the hub. This is just with 6 blueprints communicating. Without the hub this gets increasing complex and messy, where as with the hub the spider just get more legs so to speak.

            Comment


              #7
              I don't understand the mess without a hub, why are all the objects separated? And why do several objects go to the same object? I get used to a waterfall of spawns and save the reference and use the Owner variable.
              Last edited by DomusLudus; 08-24-2019, 01:57 PM.

              Comment


                #8
                Originally posted by DsyD View Post
                I don't think it will have a big impact on performance. If it saves you from using a lot of "Get All Actors ..." calls, it might actually improve performance.

                I'd say do what you need to in order to stay organized. Personally I would not find it helpful to have a single "hub" for ALL blueprints, since that seems to me like putting all of your system's files into one folder, but it might be manageable if your game doesn't have a lot of distinct BPs.

                Keep an eye out for circular dependencies, though...if BP_Hub needs a reference to BP_inventory *and* BP_inventory needs a reference to BP_Hub, you can run into issues if things don't happen in the order your planned.
                I second DsyD 's opinion. It might seem natural and intuitive to have a single Hub that knows about everything, but it's generally better to keep your blueprints decoupled. By referencing back and forth between two blueprints, it might end up creating circular dependencies at some point in the future. And if that happens, your only option would be to rewrite the classes that got affected. It's better to take early precautions and not let that happen.

                So if you're trying to keep references, I'd suggest keeping it one way. Also, you can check out these resources for finding other alternatives to the single hub workflow: http://gameprogrammingpatterns.com/contents.html. The Observer & Component patterns listed there are quite useful.
                Unreal Possibilities
                Grid Creation Systems | Tower Defense Starter Kit | Line of Sight Visualization

                Comment


                  #9
                  With a hub the compile times should also be affected. Everything that is being referenced needs a run through. Although it is convenient to easily be able to get a reference from the hub it also has a tendency for you to make functions where they don't belong because "it is easy" but in the long run you sprinkle the class responsibility everywhere making it difficult to get an overview.

                  Decoupling is important for many reasons.
                  • The obvious one is initial load times since every object being referenced needs to be loaded at once.
                  • Then you have hot reload which in my experience fails more frequently if the class has a web of references
                  • When using perforce and you revert or sync with the engine open it again has to hot reload and it will not work with many references or circular dependencies.
                  • And the compile times which I already mentioned

                  I would not use a hub but rather use the observer pattern to keep things decoupled.

                  Comment


                    #10
                    Thanks for the input all, Ill rewrite what ive already done and remove the Hub. looks like i need to just practice keeping it straight in my head. Thanks for the input.

                    Comment

                    Working...
                    X