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:

• Single wall/door locked and opened with a collectible key
• Single wall/door opens in proximity range of player
• Single wall/door opened by pressing E
• Single wall/door sliding to the right
• Single wall/door sliding up
• Single wall/door open trigged by interacting with an object
• Double doors locked and opened with a collectible key
• Double doors opened by pressing E
• Double doors open trigged by interacting with an object
• Useable on different characters for all doors

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.

This at least armed me with a few thoughts to move forward from in how this was going to be designed. After that it was time to look into unreal documentation to make sure I fully understood some new things I learned. Like how to use a timeline node that is in Unreal Engine as graph function for the timing the X, Y, and Z cords of an object for vectors and floats. This is my case would be the doors or walls positions relative to the door of their starting location.

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.

This is one of my test levels in that playground. It’s just the basic starter map. All of the doors used in it are not even the ones I’ll be using in my game either. I just wanted basics.

One of the biggest things for doors to work and will be a common thread in all of them is having a box collision. Once the player is in that collision I can have the door react by auto opening, looking for E being pressed, checking if the player has the correct key, and anything else I need. I could even have that collision be on another object the player interacts with if I want them to open the door somewhere else in the map.

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.

Not to mention any hidden doors don’t have keys anyways or can only be opened from the correct side due to how the collision box is placed. Like in the above screenshot where the player needs to trigger something from being in the range of that object. Then other things happen.

The only design flaw I have in some cases regarding hidden doors/walls/passages are some dead giveaways. Such as annoying light bleed through meshes on the other side. As we can see in this case above. There is nothing in the room the character is currently in to open this door in this example from his side. So it would drive some players crazy trying to find a hidden button or something. An issue I should be addressing when I do another pass of lighting after learning more about lighting in the future.

At some point, after I worked out a lot of the basics in my playground project and before some of the sneak peaks I showed above. I moved over to my actual game project. In there I mainly focused on getting double doors to work. Along with resolving some complications a project my scale creates to get everything to work.

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.

Final Thoughts

This ended up being simpler than I was expecting it to be. The biggest thing will be if I future-proofed these enough for the scale of a game I’m creating. Some things might need some slight change in the future. Thankfully I can do that at the blueprint level and don’t have to go manually go in and change everything.

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.

Other Posts:

• 21. Working On Items 3
• 22. Unreal Engine Makes Major Announcements
• 23.Monsters And Trying Out Different AI Capabilities

Information

Screenshots were taken and content was written by @Enjar. Screenshots are from Unreal Engine 4.