Level Design Development Log 2: Level Functionality
In this second development log, the continued development of the game will be documented until the point at which the game can be played from start to finish. Principles of level design will also be discussed if they are implemented into the level at this point.
Exterior Level Changes:
In the exterior level, the geometry around the forest area was adjusted so that the skybox can no longer be seen on the edges of the forest. This helps to sell the illusion of the path being deep in a forest when in fact the trees are only around the area that the player can see and navigate in.
Geometry Changes 2
Geometry around the hut that the player receives the flashlight in has also been adjusted. This was so the hut could be placed on flat ground as before it was visibly off of the ground. Although, this wasn’t an important change to make it was a very easy and quick thing to do.
As mentioned in the first development log, the player could walk past the hut without getting the flashlight originally. This meant that the player could avoid activating one of the level’s main mechanics and potentially have a hard time getting through the level. To fix this an invisible wall was implemented that also informs the player of why they can’t go ahead.
The blueprinting for this was very simple as it used the same variable that allows the usage of the flashlight to know when to delete the invisible wall. The UI element that informs the player that they can’t proceed uses an box collision element to detect when the player is close enough to the invisible wall so that they would need to be informed of why they can’t pass.
Interior Level Changes:
For the interior level, the first changes were made to the functionality of the platforms that appear after the player has placed the reliefs. Rather than the platforms just being toggled as being visible when the player places the reliefs a cinematic was implemented to also show the platforms rising from the water. This was achieved by using level sequences that play when the respective relief is placed into the pedestal, controlling both the respective platform and the camera so that the player is aware of the change. The camera was also included in the level sequences because originally it wasn’t obvious what the reliefs being put into the pedestal meant but with the camera the player immediately is told what has happened.
The original blueprint functionality was kept which is the blueprint detecting when the player has placed the relief associated with the platform so that the box collision can be deleted and the platform mesh can be made visible. The cinematic functionality was added after this which is just blueprinting that plays the respective level sequence.
The freezer puzzle now functions closer to what is intended. Originally the player could take the relief without any consequence and skip the whole puzzle part of the dining area. Now the player has to have obtained the fake relief to leave the freezer with the kitchen relief. This is because the fake wall of the freezer actually moves towards the player when the relief is picked up.
The functionality of the freezer wall moving is contained within the level blueprint so the locations the wall needs to move between can be set using target points within the level environment. The fake wall blueprint within the level is referenced here to and moved to whichever location it should be going to dependent on what state a variable is in known as ‘Wall Moving’. This variable is controlled within the blueprint responsible for the relief functionality within the freezer. Earlier attempts at making the wall move used similar blueprinting to what is used to animate the doors in the level but the wall movement wasn’t working correctly and it would fly off into the void outside of the level. This is probably because of how the fake wall blueprint was structured and rather than changing that the current way of achieving the same result was tried which proved to be a lot more accurate in moving the walls where they were supposed to go as the earlier attempt was done by putting in the values of the target locations for the walls manually.
The wall was now moving but the wall functionality was not yet completed to a point that was satisfactory for this point of development. To get it to that point more functionality was added to the wall that revolves around the act of the player actually being killed by the wall when the wall collides with the player.
To ‘kill’ the player a collision box is attached to the wall that calls an event within the player character’s blueprint when it detects the player. This event disables the ability for the player to move and also makes a boolean variable true that stops the fake wall from moving when it is in this state. This is only a placeholder for the player death functionality as there is going to be an UI element to it later that states ‘You Are Dead’ and then the level will restart from inside the mansion.
The first challenge the player comes across within the bedroom and office section of the level is that they need to find a way into the office as the door is blocked. To do this the player has to locate a button within the bedroom that opens the vent which allows the player to then enter the office.
When the button is interacted with it plays a level sequence that shows the button being pressed while also changing a variable so that the vent knows to open. The way the player interacts with this button is the same way most of the interaction within the game works. A collision box is used as a trigger to know when to show the UI and remove it based on when the player overlaps and moves away. At the end of the bit of code where the level sequence is activated the box collider that triggers the UI is also removed.
The vent door blueprint contains the functionality for the vent animation. After the vent button variable is set to true, a timeline is activated that moves the vent door. To know where the vent door should start and end a lerp is used which is then plugged into a SetRelativeRotation block attached to the vent door model so that the vent door will move to the position it is supposed to be at during the timeline.
The door to the office area of the mansion could be used straight away before which was not the intended flow of the area. To change this a variable was added that is used to stop the player from being able to interact with the door until they have unblocked it from the other side. This functionality was adapted from the locked door functionality as it is the same idea just with a different variable being used.
To unblock the door the player must move a chair from the door by interacting with it. The player is only able to interact with the chair from the side the door is blocked from as the collision to enable interaction with it is placed and scaled in a way so that this effect is achieved. A level sequence is used to manage the movement of the chair and after this sequence is played the variable for the door is changed so that it is now interactable. The door unblock sequence is used so that the player doesn’t have to go back through the vent and bedroom area allowing the player to leave this part of the level quickly without retreading old areas as the player already has to explore the building a lot.
One of the main puzzles of the level is contained within the office as one of the reliefs for the pedestal is obtained in this room behind a bookcase. Before the bookcase was already open and the player could just grab it. Now there is an actual puzzle to solve that involves placing three books in the right order on the other bookshelves. For now the books are placed on the table in the office itself but later they are probably going to be placed around the level. For now, there is no clear indication of where the player should be placing books as the assets aren’t yet finalised. Later the bookcases will be filled so the spaces where books should be placed will be more obvious.
The blueprints for placing the books are very large but also quite repetitive so to explain them more efficiently snippets have been shown that can be used to explain the full blueprints. When the player enters the collision for interaction with the book placements, the player has the option of placing any of the books. This is so this puzzle is actually a challenge rather than just another find and place mechanic. Each book has its own key input for example pressing 2 on the keyboard will place the second book which is told to the player in the UI. The UI for each book will only show up if the book is in the player’s possession which is detected through the use of booleans for each book. Before the player has the correct combination the player can also pick up the books after they have been placed. The above screenshot shows the functionality for placing the first book. The player can only place the first book if they are in the interaction radius and if a book hasn’t been placed yet. Once the player presses 1 the first book’s variable is now false to tell the blueprints that the player no longer has the first book and a static mesh is made visible to show the player a book is placed. The variable to detect whether a book is placed is made true and the number of the book placed is put into a float so the book the player can pick up from this location matches the one they placed. To made the UI transition more smooth the UI for book placement is removed when the player places a book and immediately replaced with the UI for picking up a book. If the player places the right book another variable is set to true that tells the blueprints that the correct book has been placed in that location.
The order in which the player is supposed to place the books is not yet able to be figured out any way except for trial and error at the moment but when the narrative elements are added to the level later there will be a hint implemented. Once all three books have been placed in their respective locations the interaction collision for each book placement blueprint is removed so no further changes can be made to the order. A timeline animation is also played that opens the bookcase to reveal the second relief. The blueprint for the second relief had to be changed a bit as it could be picked up through the bookcase. This was achieved by not allowing the player to interact with the relief until the bookcase has been opened which is controlled through another boolean variable that is set to true when the timeline animation is complete.
In a GDC (2018) talk about ‘Ten Principles for Good Level Design’ by Dan Taylor, a point is brought up about how good level design is surprising in which one of the main points was to disrupt paradigms within the level. A specific quote from the talk is “be subversive, take an existing game design paradigm… and flip it” which has been attempted to be implemented in this level. After the player has obtained the second relief, the floor in the hallway of the bedroom and office area will break and cause the player to fall to the kitchen area. This is to disrupt the pacing paradigm of the level as the player has been free to explore the level however they wanted at this point and this shift to a different area is something that changes up the level flow unlike the rest of the level. The floor breaking was achieved using an Unreal Engine plugin called Apex Destruction that allows any static mesh to be broken apart inside Unreal Engine itself rather than doing it manually. The plugin allows a destructible mesh to be created that can be broken inside blueprints so when the player enters the collision for the part of the floor that is intended to break the destruction is activated and physics are added to that part of the floor so that it is affected by the simulated gravity.
The safe puzzle is the final puzzle needed to obtain all three reliefs. As the case was with most of the other puzzles, before the relief could be grabbed out of the safe without doing anything as the player. However now the player must enter a four digit code into the safe for it to open. The code currently is 1234 as a placeholder as the actual code in the final level will be found out by searching the nearby guest rooms. For now there is no indication of what the code is in the level. The relief inside the safe was adjusted like the second relief so that it can’t be interacted with until the safe is opened.
The keypad UI blueprint is shown above. Each button on the keypad is stored within an array so that when they are pressed the number they are assigned to is added to the display on the keypad. This is done by append the digit of the respective button to the variable that is used for the display and then setting that as the variable. To get it to show up on the display the variable is converted to a string variable. The length of the keypad variable is also detected at this point to see if it has reached four digits so the code can be checked. A event dispatcher is called at this point known as Code Entered.
The blueprint for the buttons was set up in a way that would allow each button to stem from the same blueprint. This was achieved by making the digit integer variable public so the value could be changed for each button in the keypad blueprint when they were added. To make this value be shown on the button it is applied to the text on the button before the keypad UI is loaded into the game.
The top line in the safe door blueprint is used to create the function in which the code is checked when the keypad blueprint has called the Code Entered dispatcher. The bottom line is a timeline animation for the safe door.
This screenshot displays the function in which the code is checked which is done by comparing the input code variable to another variable. If it is not the right code, then the input code variable is reset to allow the player to input another code. If it is correct, the timeline animation is played and a variable is set to allow the relief inside to be interacted with. The keypad is deleted at this point but it will be adjusted later so that the ability to input a code onto it is removed rather than the whole keypad.
The final element of the level is contained within the living room. The goal is to recreate a scene within the living room by finding an item and placing it where it is intended to go. For now it is very simple as it was implemented to just allow the player to finish the game. In the final version of the level, this sequence will be a little more complex as it will involve a level sequence when the player places all of the items.
Some of the functionality for the living room section is contained within the level blueprint. This is so the arrow used to tell the player that there is somewhere to go down the hallway will only appear when the player is supposed to go to living room without creating a new blueprint class for the arrow and instead just referencing the static mesh that is placed in the level. The other bit of functionality stops the player from moving and performing any input when the scene has been finished by tracking the boolean variables for the different elements of the scene. This serves as the ending of the level for now. An idea for the final version of the ending has a UI element appear to inform the player of the ending and then the game will quit.
References:
GDC (2018) Ten Principles for Good Level Design [Video]. Available online: https://youtu.be/iNEe3KhMvXM [Accessed 15/04/22].