One Blueprint - Multiple Functions... Is This Possible?

[The_Solo_Artist]

Hello Unreal Family!

I am newer to the development side of the house so please forgive my ignorance. I have searched for days to try to find an answer to my question but, I came up short. So, I decided to post here hoping to find the much needed salvation I am looking for!

I do not have any code to back up my question. It is more of a theory at this point in my development. I’ve made levels before (many years ago) and I always took the long and pain staking way to achieve my goal (because I didn’t really know/understand how to code properly). I am trying to completely change that way of thinking and actually code more and design less. So, with that said, here is my question…

Lets say I am making a game and I have a basic door (with door frame) Blueprint. I have it coded in a timeline to open when activated. All fine and good there. However, I’d like to use this Blueprint of the door for numerous purposes without making a separate blueprint for each purpose. For example:

1. As a locked door in hallways - For aesthetic purposes, you can’t have a hallway without any doors in it! I would like to place multiple instances of this door going down a hallway and have the door not function/open at all, but if the user were to try to open this door, they would get a sound effect of a locked door and an audio cue that says “This door is jammed and wont open.”.

2. As a functioning locked door in a room - There is a key in the room with this locked door that you have to locate. If you try to open the door (without the key in your inventory), you would get a sound effect of a locked door and an audio cue that says “This door is locked. Maybe there is a key around here.”. Once you find the key (it is placed in your inventory) and you are able to use the key on this locked door and gain entry and progress through the level.

3. As an automatically opening door - Through code and triggers, this door opens automatically once an event happens (timed event or BeginOverlap event, etc).

One main caveat to this game is that the entire level is procedurally generated.

So, with all of the above being said, is it possible to utilize one blueprint of the door to achieve all 3 functions or will I have to create 3 separate blueprints of the same door and just code each function separately on each instance of the door blueprint?

I apologize if my question doesn’t make sense. Please let me know and I will try my best to further explain it! Thank you all in advance. I’ve been creeping around the forums for a while now, and everyone really seems helpful and understanding!

[Jezcentral]

You could do this with one blueprint, you would just have to have two boolean variables that would say something like:

1. Jammed/Unusable: locked=true, openable=false
2. Locked: locked=true, openable=true, and the key would change this to locked=false
3. Usable/Unlocked: locked=false, openable=true

This would mean they have shared behaviour. Door 1 would mentioned the “jammed” message because of the openable=false when locked=true, when the player tried to open it. Door 2 would say that the door is merely locked, because openable=true, even though locked=true. When door 2 is unlocked, it “becomes” a door 3. You could then allow the player to open door 2 and door 3 using the shared behaviour.

[The_Solo_Artist]

@Jezcentral

You could do this with one blueprint, you would just have to have two boolean variables that would say something like:

1. Jammed/Unusable: locked=true, openable=false
2. Locked: locked=true, openable=true, and the key would change this to locked=false
3. Usable/Unlocked: locked=false, openable=true

This would mean they have shared behaviour. Door 1 would mentioned the “jammed” message because of the openable=false when locked=true, when the player tried to open it. Door 2 would say that the door is merely locked, because openable=true, even though locked=true. When door 2 is unlocked, it “becomes” a door 3. You could then allow the player to open door 2 and door 3 using the shared behaviour.

Jezcentral,

Thank you so much for your insight! What you say makes sense to me. I didn’t consider utilizing a BOOL for “openable” in my logic. But that does make perfect sense!

I am trying to consider different computer setups with my end product. I want to “trim the fat” (so to speak) on anything that could be done under one blueprint (in this case, a simple door). I don’t know how much having one blueprint of the door to handle all of these different processes compared to having 3 door blueprints (one for each process) would be on overall CPU/MEM/etc usage. Since the game is procedural based, I’d figure loading/setting up the level itself would be taxing enough for a PC. Plus, I want to challenge myself out of my comfort zone to learn more about development and coding.

I am definitely open to any/all suggestions though! I like to consider any possibilities before making a decision.

[The_Solo_Artist]

@AntiGravity

If the code will grow beyond a few simple bools then you might want to look at inheritance as well. Have a base class that has the door and the basic logic, and then override that with whatever flexibility you need in child BP’s. Another possibility is to keep the Door BP as basic as possible, and have a Door Controller BP that has the logic to control the Door BP, or even a pool of Door BP’s. The question you haven’t alluded to yet is what creates CPU bottlenecks anyway? At its simplest, its having things tick that should be idle or on timers.

To give a meaningful answer as regards performance, you need to be specify the target hardware and estimate how many of these procedural doors you’ll need. If your target is PC and you’re worried about having 200-2000 of these in a scene / level, then I wouldn’t be. On the flip side, if your target is mobile and there may be 20k-200k or even 2 million Door BP’s. Then yes it will all add up. In that case, you may have to explore other options. Such as dynamically substituting static-mesh doors for ‘active’ BP doors (if & when players / cameras are nearby), along with level streaming and other options.

As regards GPU load. There are a lot of instancing tricks available, including having UE auto-manage that (in recent versions of UE). as long as the doors are static-meshes placed or spawned in the level. But what if the static meshes are part of a BP? If your search the forums, there are some interesting threads where devs have run benchmarking tests using various instancing techniques.

UnrealEnterprise,

Thank you for your input! I like the idea of having a Door Controller BP. Another reason why I wanted to try to have the smallest amount of BPs for a singe object as possible is to be able to add/edit either the objects or the code in once place. That way everything in the level will update at once rather than having to update every item on a level individually. Almost like a CSS for a website. Many years ago when I made levels or mods for my favorite games, I would painstakingly place objects all over the level and then have to go back and edit every instance of that object because I was not savvy in the development/coding field. I was young, dumb, and would rather just jump into my creation ASAP.

I digress… In terms of bottle-necking, this project would solely be for PC. One reason I am keeping the PC specs in the front of my mind is because when I used to make levels, my PC would bog like crazy. I wouldn’t want that to happen to anyone that would play on my levels. Also, I am still learning UE; anything from the basics to the advanced. The levels I am building are on an i9/64GB RAM/2080TI. But, would my finished project play on a 10 year old i5/8GB/1060? I try to consider as many outside factors as I possibly can. Granted, I know I will not consider EVERY possibility, but if I can mitigate those negative factors in order to have a quick loading, smooth playing game, then heck yeah!

Another point I am considering is the possibility to have these doors become damaged and break. There will be an AI component to this project at some point as well. The AI will be the ones breaking down the doors.