One of the things I’ve wanted to add to my game for a while now is working doors and hidden walls for the player to find if a map has any at all. This ended up being easy and only took me a couple of days of implementing it in my current 15 maps if they needed it.
First I needed to determine what functionality I needed:
While I ended up using a base to build each of these doors or wall functions off of. Some differences needed to be taken into account. For instance, treating double doors as single doors had some amusing results. Such as the doors rotating in the door frame blocking the player from entry. Also not every single door needed all functions available so I ended up having a few different blueprints depending on the use case.
My first course of action in trying to understand how to solve for my above problems was to take a look at the live working examples I have within Unreal Engine. There is a couple of working door examples in some of the assets I’ve downloaded from the Unreal store in the past.
The biggest issue I often run into when going this route is there is no direct documentation explaining things. Many times these examples that are in Unreal Engine are done by professional wizards as I view them at this point.
In one of them I could not even work out how they were getting the doors to trigger with E being pressed. I found what I thought was the function calling for such action. Expect, there was no visible coding in the blueprint or file settings in Unreal Engine that trigged when E was being pressed among a few other things. It “just did” aka I don’t have enough understanding in how the heck these wizards pulled it off.
I then loaded up a test project that I consider to be my “playground.” If that environment gets wrecked it’s not a big deal and I can start from scratch. Everything in it is separate from my main game as sometimes I play with settings and other things that could cause a lot of things to change and break.
It’s not an exact duplicate either of my game. As there tend to be about fifty gigs worth of data difference between the two. It is also set up much simpler than my game so I can first work out basic things before solving at a more complex design to work in my game.
There are also some important details to keep in mind as well. Such as from where is the door opening from. While that was not as important for say a Wall that could just slide enough in the direction I wanted it to go and easy to fix with a single number. Something like double doors that becomes quite an important detail.
There were also some things I did not think of beforehand in what I wanted my door system to do. Such as what happens to the door after the player opens it? I ended up liking the door closing in most cases once the player leaves the collision box. This dose allows the player to block and hold back monsters who can’t trigger doors if they wanted to skip over killing them. I did some testing to see how sneakily a player could be to use this to their advantage.
I’m happy with my current results. If the player gets too many monsters on them and the door closes and reopens the player can use it to try and divvied up a horde to make it more manageable. Range attacks I’ve always made to destroy on impact with something so the door would stop the damage. If a player just wanted to skip over killing something they would miss out on possible loot opportunity.
In an instance where I feel it would matter the door will simply remain open. In other cases such as fighting bosses those maps do not have any doors to open at the start. So the player could not try and exploit that to sit and regenerate health and/or mana.
For the more complex doors the player just needed a blueprint actor they could pick up that held an integer value for the door. The door than just needed to check if the player had that integer variable correct for that individual door before allowing them to open by pressing E.
Another thing that had to be kept in mind is managing how many of these integer variables the player could hold. Since keys are not something that is saved after the player leaves my upper limit is just how many possible keys I even want on a map. Most of my maps only have a couple of locked doors. At most they can have a couple more than that as a future-proofing measure.
If I felt I wanted something more secure than that I could always add in another variable and make it unique and have it save. This is not something that is the most important thing ever. If the player finds an exploited to bypass these locked doors. It’s not like any of them are securing loot just all by itself for easy pickings. The player would miss out on killing monsters for experience and loot if they just skip over things. Speedrunning a map and not killing things is anti-productive for how other systems will be designed later on which I won’t be getting into here.
Once everything was done and tested. it was time to roll everything out. The only issue is when I made my current 15 maps I did so without any thought on the function of the doors themselves. There is an endless amount of things to consider and sometimes you miss something as I have for this.
Turns out I wasted some time messing around with moving doors around on the frame trying to make them look a certain way in a given scene in the past. They were also all the same door as again I did not have any thought of futureproofing it.
As a result they all manually needed to be replaced and I had a couple of hundred doors. This is also when I spent the time working out what type of function the door would in the spot. Along with the finer details like where keys or other triggers would be placed in a given map. Then I tested everything to make sure I had key values right so they worked with the correct doors and nothing else broke or was forgotten.
There are a couple of things that still need to be added in future updates when I get around to doing those systems. Sound for interacting with the door if I can acquire a commercial license to use. Maybe I’ll add to the player's HUD some text that will show up if the door is locked or to press E to open. Which on that last part I’m not 100% sure I'll add as I’ve never been a fan of that kind of text popping up.
Screenshots were taken and content was written by @Enjar. Screenshots are from Unreal Engine 4.
