Game Summary

Fluff Brawl Bros is a 2-player action fighting game, where players must battle it out over 4 floors, by knocking the other player down to the lower level. This is whilst the floor is constantly being destroyed by laser turrets and player abilities! Each character has their own ability to be utilised to get an edge over the other player, whether this is an area of effect, dash, double jump, etc ability. The last player standing wins!

Tutorial Steps

project setup

Ready to get started on adding a customisable door system to your project? First, create a new Unreal project using the Blueprint version of the third-person character template. Then, set up your folders - a "Blueprint" folder and a "Data" folder within your content folder. Within the "Blueprint" folder, create three more folders: "Character," "Interactables," and "Interfaces."This is optional but move the pre-built BP_ThirdPersonCharacter class into the "Character" folder, and later, we'll cover the "Interactables" folder. In the "Interfaces" folder, create a new Blueprint Interface named "BPI_Interact" and define a single function called "Interact."Finally, create an interaction button in the project settings under input by creating a new action mapping "Interact" with the input being the 'E' key. With these steps completed, you'll be ready to move on to setting up the player character.

player character

In this section we'll be creating the interaction system to use the doors. To start, go to the Event Graph inside the player character and find an empty space. Right-click and select "Interact" Input Action. Then, create a new function by clicking the "+" button under the Functions tab on the left side. Rename this function to "InteractTrace".Next, we will use the LineTraceByChannel function to check if we have hit an actor. To do this, get the follow camera and its world location and forward vector from the component. Plug the world location into the start input of the trace function, which will be the starting point of the trace. Then, multiply the forward vector by a variable you need to make named "InteractTraceLength" (set to 750.0 and to use the float data type) and add the result to the world location. This will give us a new vector in world space, 750 Unreal Units away from the current camera location. Make sure the line trace uses the visibility trace channel.Check if the trace is valid by using an "Is Valid" node and on the "Out Hit" of the line trace get "Break Hit Result". Get the "Hit Actor" from the "Break Hit Result" and plug it into the IsValid node. Create a Return Node and connect it to the "IsValid" return. Drag the hit actor to the return node to create a new output (name it Hit Actor).Note: We should call this trace client-side and only verify it on the server if it hits something. It's also a good idea to double-check that the hit actor implements the interact interface to save server resources.Head back to the event graph and connect the new function to the pressed pin. On the return execution pin for the "InteractTrace" function, use an IsValid node and check if the player is a client or server using the "Switch has authority" node. If the player is the server (authority), call the "Interact" interface function on the hit actor. If the player is a client (remote), create a custom event RPC named "ServerInteract" and set it to "Run on Server" and "Reliable".From the execution pin of the new event, call the "InteractTrace" function and check if the HitActor is valid. If it is, call the "Interact" interface function on the hit actor. Now that we are the server and have authority, we don't need to use the "Switch has authority" node.Finally, call the "ServerInteract" event on the remote execution pin of the "Switch Has Authority" node in the event graph.

door class

Now for the meat and potatoes! Let's move on to why you came to this tutorial! The doors. Before we open up the class, navigate to the data folder we created at the start and create a new folder named "Curves" inside we're going to create a new float curve. To do so right click in the content browser and select miscellaneous->curve and in the pop-up box, select "CurveFloat", this will be used for opening the door. Name this "C_Door". For the keys inside the curve editor. We're going to simply just have the first key at 0,0. (Middle click to create a key) and the second at 1,1. (We'll be modifying the play rate in the blueprint so we can assign custom times to each actor we place in the level, instead of being restricted to a set time or having to create multiple curves.)Now we can head back to the event graph! From the RPC we made an earlier call for a branch node from the execution pin (Holding B and left-clicking is a neat little shortcut), now click on the "CanUse" function and check the pure option in the details panel. Drag the function into the event graph and connect the return value to the branch.
Now we can go and create the door class. Go back to the "Interactable" folder we made and right-click and select "Blueprint Class" selecting "Actor". Name this BP_Door_Master (the suffix of "Master" is used as this will be the parent class of children we can create based on this actor to create different doors using the logic from this base class.
The very first thing to do is go ahead and set up the actor replication settings. Navigate to the class defaults (the button is on the toolbar at the top) and scroll down in the details panel till you reach replication. Turn the check box called "Replicates" on we'll be coming back here in the optimisation section as we have quite a few different options we can change to improve bandwidth.
From there, head to the components of the class and create 3 new static mesh components. Naming them "SM_Door", "SM_DoorFrame" and finally "SM_DebugDoor" (The debug door will be used to visually place and pivot the door in the level or blueprint to reflect where the door's final transform will be. I feel this method beats having to input manually their transforms. In the "SM_DebugDoors" details panel we simply just have to ensure there isn't any collision by finding the collision preset and set the drop-down to "NoCollision" also check the "Hidden in Game" checkbox as this is only supposed to be used to store a transform.
We now need 2 more components,
one being a "Box Collision" which shall be used to see if a player is overlapping and an "Arrow Component" to see the direction of the actor when placed in the level.Within the "Box Collision" details panel make sure to set the boxes' extent, for me I found (296.0, 48.0,112.0) to be good values.Now to setup up the meshes. Open up the construction script, this is called before "Begin play" and outside of runtime. We're going to now drag the "SM_Door" component into the graph, dragging off from that and calling the "Set Static Mesh" function. With this, we'll right-click the "New Mesh" input and promote this to a variable named "DoorMesh". Make sure this is an instance editable in the details panel and assign it the mesh you'd like for the door. Then do the same as before for the "SM_DoorFrame" so drag it out, call the "Set Static Mesh" and promote the "New Mesh" to a variable named "DoorFrameMesh".For now, we're going to move over to the event graph (We'll be coming back here soon to set the timeline play rate and debug mesh).
Firstly navigate to the begin play node, if there isn't one right click and get one! From the execution pin call for the "Switch has Authority" node again, now create a new transform variable named "InitialDoorTransform", making sure it's set to replicate in the details panel. Drag this variable into the event graph and set it; connecting it to the remote execution pin.
The value we'll be setting this to will be the "SM_Door" relative transform. So go ahead and get the "SM_Door" component into the event graph and off of that get the relative transform and connect that to the "InitialDoorTransform" left-hand side pin. Then simply call for the force net update function after the execution pin. I'll explain this node later.Now head to the class settings (located at the top in the toolbar) and add the interface we made "BPI_Interact" to the implement interfaces section.Once done, go back to the event graph and implement the interface function by right-clicking and searching for "Event Interact". This shall be triggered by the player's character. We now need to create a new custom event RPC named "Server_ToggleDoor" making sure this is set to reliable and "Run on Server". Call this event on the execution pin of the interact event.Now we're going to need a new function to be made named "CanUse" this will be there to check if the actor can be interacted with and if the door isn't locked. Once created open it up. On the left create 2 new variables. "Can Interact" and "Locked", this doesn't need to be replicated as they aren't updated during runtime. Now to finish this function all we need to do is get both these variables inside the function, off of the "CanInteract" drag out and call the "and" node. In the second pin of the "and", get the "Locked" variable, drag out and get the "not" note. Plug this return into the second pin of the "and". The execution pin of the "and" add a return node. and plug the returned bool from the "and" node into the return node.Following this drag out and call the sequence node. Now we need a new boolean, named "IsOpen" make SURE this is set to be replicated. On the second sequence pin set the newly created variable and for the value we're setting it to, get the "IsOpen" variable and get a not node, plug this into the set pin.On the first pin of the sequence we need to call another branch and for the condition get the "IsOpen" variable and get the "not" again. Plug this into the branch. The reasoning behind needing the sequence is that we need to get the "IsOpen" value before it's set, and if we set it later it won't be as clean or it'll be too late if performed after the upcoming timeline is finished.On true, add a timeline by right-clicking and finding "Add Timeline", and name this TL_Door. Open this timeline up and set the curve to use the external float curve we created earlier by adding a floating track and selecting the external curve. Set it to replicate by selecting button three to the right of the timeline length. Now we've finished with the timeline, go ahead and in the event graph plug the false pin into the reverse pin of the timeline. Making sure the branch's true execution pin is into play (Not "Play from start").On the updated pin for the timeline, we'll need a new function! Let's create it and call it "DoorTransform" This function shall take 1 parameter named Alpha with the data type being a "float". Inside the function, get the "SM_Door" component, and "Set Relative Transform", for the new transform we need only a little bit of logic to find the correct transform.First get the "InitialDoorTransform" variable we made earlier, off of that call for the lerp function, this variable will go into the A parameter. Then get the "SM_DebugDoor" component and get the relative transform of that component, making this returned value go into the B value.
This shall give us both the initial transform and the target transform.
For Alpha, we're going to just use the Alpha input for the "DoorTransform" which we'll update outside of the scope of the function. Making the "Interp mode" to "Quat interp". Then plug the return of the "Lerp" function into the "New Transform" pin of the "Set Relative Transform". Finally, add the node after setting the transform and on the execution, the pin gets the "Force Net Update" node.Now we've finished with that function, plug that into the update execution pin of the timeline. With the float value from the timeline being plugged into the functions alpha pin.Finally, to finish off the interaction for the doors, we just have to go back to the construction script and set up the timeline and debug the door mesh.
So let's head into the construction script, last time we were in here we set the door frames mesh. Next, we'll do the timeline, go to components in the variables and get the "TL_Door" or whatever you named your timeline in the event graph and drag it in. Then drag off of it and get the "Set Play Rate" node. For the new rate, this will be super simple, all it is is getting a division node. With the first pin being set to 1.0f. The second is the door speed. For cases where we'd like to change the speed on, simply promote the pin to a variable named "DoorSpeed" this doesn't need to be replicated. Compile and set the variable to a default value of something like 0.6f. Also, make sure the variable is set to instance editable.Now we're moving on to setting up the debug mesh. Go ahead and create a new boolean variable which doesn't need to replicate named "ShowDebugDoor" and connect it to a branch, with the execution pin from the play rate going into the branch. Next up we need to drag the "SM_DebugDoor" into the graph and call for the "Set Static Mesh" function, with the "NewMesh" being the "DoorMesh" variable we set up earlier. Afterwards, this is optional but with the debug door drag off again and call the "Set Material" node. In the material pin, get a select node and with the index set that to the "Locked" variable we made. Now then in the true pin of the select, click it and find a material you'd like to use to show you it's locked. I used a generic red engine material. With the false pin use another different material, I used another generic engine material. Now, this shall make it show visually on the debug mesh if the door is set to be locked or not. This is great for when creating levels and knowing which doors can or can't be opened without having to click on each actor within the level.Now if you're not wanting an overlap event to trigger to open the door too, you can skip to the next tutorial step. Though if you'd like the extra customisation to feel free to carry on reading!So now that we've finished all that let's jump straight onto the overlapping events. Go and head over to the event graph, right-click anywhere and get both the "Event ActorBeginOverlap" and the "Event ActorEndOverlap".
Starting with the "Begin Overlap" event, off the execution node "Cast to Character" which will check if the current overlapping actor inherits from the "Character" class. Connect the "other actor" to the object of the cast. Do this also for the "EndOverlap" event. We're nearing the end finally but we do need to create a new function. Let's call this "CanOpen" set this to be pure like previously mentioned and have both an input and output of data type "bool".Within the function, drag the box collision component into the graph, off of that "Get Overlapping Actors" with the class filter being "Character", we do this so it only returns actors which inherit from the "Character" class. With the array returned by the function get the length. We then just need to get a >= node with the second pin being 1 and a > node off of the length with the second pin also being 1. Off of both the >= and > nodes call a "not" node on both. Now get a select node with the index being the function we're in's input bool which mine is named "Open", and the false of the select being the >='s return on the not node. The true select pin is the > not nodes return. (Feel free to look at the screenshots posted if you're confused!) From the select node, add an "and" bool node, which will have the first pin being select, the second being needed to be promoted to a variable named "CanOverlap" which won't be replicated but will be instance editable and thirdly the "Locked" variable we made with a not node coming off of the bool and going into the third pin of the "and". If you're finding it hard to add a pin to the "and" node so we have 3 inputs, just click the "Add pin +" button on the node itself. From there add a return node to the function and drag the returned bool from the "and" node into the return node. We made this function based on the input bool, it checks if there are any players currently being overlapped to stop the door from shutting or opening prematurely. Also to check if the door can be overlapped and isn't locked.I promise we're nearly finished here, head back to the event graph and create a new RPC custom event named "Server_OpenDoor" which will be set to "Run on Server" and also reliable. With an input of type bool named "Open". Off of the execution pin, get a branch node with the condition being the function we just made so go ahead and drag that out! For the input of the function make that the custom events output pin "Open" and the return of the function to be the branches condition. Next up is to set the "IsOpen" bool we made earlier, to be the "not" value of the custom events "Open" value. Check the screenshots if you're not sure! From there just simply hook the exiting execution pin into the branch we made before the timelines execution pin.WE'RE FINALLY DONE!You can now go and fully test it, remembering to check all variables we've made values to make sure they're set up right. With the meshes set, Door speed set, Updating the debug doors pivot and/or location. Also if it can be overlapped, interacted with or if the door is locked. Remember this can be set up both in the actor itself or in the level by clicking the actor and modifying the debug mesh component or clicking the actor and changing the default variables we made in the details panel.

Optimisation

For the optimisation, we'll be covering both performance and networking optimisation. To begin we'll be focussing on the doors class itself. Open it up! The majority of these optimisations will be tweaked to the actor itself which will reduce its overhead. First of all, in the class defaults (located in the toolbar at the top), we're going to be unchecking the "Start with Tick enabled" checkbox which is very important in all actors who don't need to utilise the tick function. Thus, preventing the actor from constantly ticking when it doesn't have to. Secondly uncheck the "Allow tick on dedicated server", although the actor doesn't have the tick enabled it doesn't hurt to uncheck this option too! We can also uncheck both the "Can be damaged" and "FInd Camera Component when View Target" as both of these won't need to be used.
Now let's have a look at the replication settings. In the replication category, there is a plethora of different options to add, remove or tweak. We'll be focussing on which changes we should change for this actor specifically. First of all, let's uncheck the "Call Pre-Replication" bool, all this does is when the game is loaded and is being played the engine will find all actors which have this box checked and is called right before replication occurs. This is only meant to be run on the server.
Next up is "Call Pre Replication for Replay" which we also don't need for the reasons above. Nothing in this actor needs to be called during the pre-replication stage.
The most important of all these settings is the net dormancy, ensuring this is set to "Dormant All" which tells it to pretty much turn-off, ignoring any data sent lowering the bandwidth needed. This is similar to how Fortnite has so many actors, instead of them constantly updating all clients, it instead only updates clients when it needs to. For us, we'll have the doors dormant up until they're interacted with. This is what the "Force net update" node deals with, manually being able to update all clients to the current state of the actor at any time, making it so that when a door interacts with clients are only updated at that specific point rather than constantly throughout.
Next up is the "Net Update Frequency", as this actor doesn't need to be updated constantly, we can lower this value significantly. This value is the frequency per second in which the actor itself is considered for replication, for a character sure this can be higher but for a dormant and less frequently used actor we should most definitely lower this value. I've set mine to a value of 50. Although it can be reduced a lot more! I'd recommend trying the network emulator in the project settings, to simulate clients on a poor connection and how they'd react to the actor. Although I haven't changed this one it is very important... Which is "Net Cull Distance Squared" which is the distance from the actor in which the actor will replicate, anything client outside of this zone shall not be updated, although if playing on a peer to peer the server will always be updated as it's the server which knows about the majority of what's happening at any given time. This value will be very project specific and shall need to be decided upon with testing. Although if you can't figure out the size, another option is "Always relevant" which I don't recommend setting, although you could set this during runtime and potentially make the "IsOpen" variable a rep notify and update the "Always relevant" bool and set a timer for to revert it to false after one millisecond.
Other options to look into for better optimisation would be the "Net Priority" (lowering this value means it's less likely to replicate to clients, whereas increasing it shall make it a higher chance of replicating. Although this is only noticeable when a client has a really poor connection. A value of .5-1) should be fine! Try experimenting with it.Another thing to bear in mind, which isn't project performance related but increasing development efficiency is variable organisation, commenting out code and hiding variables from the defaults. To organise the variables, simply click them and head to the category section, you can assign a category and if you'd like a subcategory you can use the '|' character. An example of this would be "Config|State" with config being the parent category and state being the child. You could even have children within children!
Next up is hiding variables which we don't want to be modified outside of runtime. You can do this by clicking the variable and checking the "Advanced Display" checkbox. To comment anything out, you can use the shortcut 'C' when selecting nodes, and it'll create a comment block you can edit and word to describe what each section does.

Conclusion

In conclusion, we have discussed and gone through the entire process of creating and setting up the door system. Furthermore, went over optimisations which can greatly benefit your project which will be easier to notice the larger the project is. It's always better to optimise as you go than go back and do it near the end of the development process. The doors are functioning and can be locked, overlapped, interacted with and positioned to reflect the transform which is user-defined. The speed at which the door is opened and closed can be adjusted and children can be created to make a large quantity of different unique doors to be used throughout your level.Feel free to download the project files below if you have any issues! Or would like commented code to better understand everything.Thank you for reading and hopefully, you've learnt a thing or two!

• Back

Projects

Projects

Projects

Responsibilities

As a seasoned network programmer at DreadXP, I am a key player in the creation of compelling gameplay mechanics for both single and multiplayer networked games. Guided by a talented ensemble of programmers, artists, animators, designers, and sound engineers, I engage in the conceptualization, design, and implementation of novel features that bring excitement to the projects I work on.My technical expertise lies in writing efficient, readable code with a combination of Blueprint and C++, while I also embrace the challenge of exploring emerging technologies to ascertain their suitability for our current or future endeavors.In addition to my primary role, I am assigned a variety of secondary responsibilities that broaden my skill set and contribute to the overall success of the projects I work on, including but not limited to:• Fixing persistent bugs
• Maintaining plugins and tools
• Integrating UI
• Contributing to design
• Creating editor tools
• Integrating audio
• Optimizing performance