Major Project Development Log 1: Prototyping Mechanics
Overview
This development log will document the creation of the gameplay mechanics and the implementation of them into the gameplay scenarios as the game further develops as this is my main priority as well as any extra work I do for the project. I began by prototyping some of the mechanics in a test environment to check the mechanics worked before adding them to any work other team members had done.
Crouching Mechanic
Pressing Left Ctrl on a keyboard allows the player to crouch which is intended to allow the player to find hidden clues. I didn’t want the player camera to move with the player animations so I didn’t connect it to a bone in the player skeleton. This meant I had to implement the crouch in a different way.
Usually, the Crouch functions would be enough but the camera isn’t connected so I have to manually move it. I used timelines and vector lerps to set the relative location of the camera so that it wouldn’t teleport to the end position and would move there gradually over the length of the respective timelines matching the animations. I used vector variables, made using values that matched the position of the camera if it were connected in standing and crouching positions, that were plugged into the vector lerps. To make sure nothing clipped with the camera, I hid the spine_01 bone of the character.
Picking Up Clues
The player can pick up a clue by pressing the Left Mouse Button when in it’s vicinity. Clues will be found throughout the game that change aspects of the game. Currently, they just change some dialogue but later they will be used to solve the murder and unlock hidden areas.
A collision box is used to detect when the player is overlapping. This sets a boolean that allows the player to press the interact key to pick up the clue. A message is displayed in the UI when this can happen via a function from the HUD blueprint. When the player interacts with the clue, a boolean variable is set in the gamemode blueprint (this blueprint can be accessed in any blueprint) to indicate that it has been collected and the clue actor is destroyed.
The visibility of the interact message depends on the value of the Show Message input which is set when the Display Message function is called which allows the function to show and hide the interact message.
Dialogue System
The player can talk to NPCs by pressing the Left Mouse Button near them. Multiple questions can be asked with one having different responses depending on whether a clue has been obtained. Dialogue ends after any option is picked but eventually the dialogue will loop so dialogue doesn’t have to be reinitiated to choose all options.
I used this tutorial series by Ryan Laley as a basis for the dialogue system. Although, I made various changes so it functioned how I intended.
The player has a box collision that checks for overlaps with an actor that has a specific blueprint interface. This interface is called “Interact Interface” which includes one empty function called “Interact”. This actor is set as the value of a variable called “Interact Actor” to be referenced later and a “Can Interact” boolean is made true. Once the actor no longer overlaps, all these changes are reverted.
Interacting with an NPC changes the camera shown to one focused on the NPC. The player is hidden as well as player and camera movement being disabled. The “Interact” function from the “Interact Interface” is called.
NPCs are controlled by an AI controller blueprint called “NPC_AI” containing two events responsible for part of the dialogue functionality. “StartDialogue” runs a behaviour tree that acts as the dialogue tree for NPC conversation. “EndDialogue” stops the dialogue tree and calls an event in the player blueprint that reverts the changes for the dialogue.
The NPC blueprint is modular because I made public variables that are changeable for each instance that determine the NPC’s name and dialogue tree. The dialogue tree variable is used in the “NPC_AI” blueprint to set the dialogue tree. The model of each instance can be changed by default. The “Interact” function triggers the “Start Dialogue” event from the “NPC_AI” blueprint. Another event in the NPC blueprint called “Angry” is used as a placeholder to show when a change happens because of specific dialogue by showing an angry emoticon on the NPCs face.
The dialogue tree operates using composites, tasks and decorators. I created modular tasks allowing them to be reused even in the same dialogue tree and custom decorators used to determine what needs to happen based on different factors.
Composites:
Sequence: Executes all of the connected blocks in left to right order.
Selector: Selects one of the connected paths to go down with decorators indicating what path to choose.
Tasks:
StartDialogue: Shows the dialogue UI, sets the NPC name in the UI using the public variable from the NPC and enables the mouse cursor.
DisplayLine: Shows input text in the dialogue box UI. To progress the dialogue the player must interact again.
AskQuestion: Allows the player to choose a response to a question. They are set in the task values for each instance. The amount isn’t limited but too many may break the UI.
TestNPCAngry: Initiates the NPC angry event and also changes the dialogue so they no longer allow questions.
EndDialogue: Hides the dialogue UI and mouse cursor and initiates the “EndDialogue” event in the “NPC_AI” blueprint.
Decorators:
CheckClue: Checks if the player has obtained the clue.
CheckDetected: Tracks whether the prototype murder has been solved by picking up the clue and confronting the NPC.
CheckResponse: Checks if the chosen response is the one needed to progress to the part of the dialogue this is attached to.
Perspective Swap
Pressing F on a keyboard swaps between first and third person. The crouch only works in first person as that perspective is for investigation while third person is for when the player is walking around. The player can switch at anytime but that isn’t how the feature will work eventually.
The perspective change will only work if the player isn’t in conversation and if no camera change is already happening. The two branch blocks with booleans as conditions track these things. A flip flop block allows the perspective to toggle using two sections of blueprinting like the crouch mechanic. Another branch in the third person section determines if the player is crouching so it can be toggled before the camera change. A boolean variable called “FP?” is used to track the current perspective. It is false in third person and true in first person. The camera needs to be attached to different components for each perspective. The third person camera needs a camera boom so it doesn’t clip with the environment while the first person camera only needs to attach to the player.
The transitions use timelines and vector lerps so the camera doesn’t immediately change. The third person transition unhides the character’s head which was hidden to avoid clipping with the camera. For first person, the head is hidden on a delay so it isn’t seen during the transition. In third person, I didn’t want the player to rotate with the camera so the “Use Controller Rotation Yaw” boolean is disabled while first person enables this because not rotating with the camera would be unnatural for the character’s perspective.
Evidence Board
Pressing F opens an evidence board. This version already has three clues on it to test out a mechanic to connect clues. Clue 1 and 2 connect while Clue 3 is just a red herring.
A Flip Flop block swaps the visibility and ability to interact on and off with the F key input. The mouse cursor is shown and the input mode is changed to Game and UI so the player can click on clues. The movement and look input is disabled while on the board so the player doesn’t accidentally displace themselves.
Clicking a clue checks if the connection has been found and informs the player. The first clue clicked sets the value of a text variable called “First Clue” with this clue’s value and sets the “Clue1Set” boolean true. The second clue clicked sets the “Second Clue” text variable and compares both clues with the solutions from other text variables. The connection will then be solved or the booleans will reset. Either way, the player is informed.
Perspective Swap Change
The perspective swap now happens when the player walks through a doorway. I kept the existing functionality but instead of an input event a custom event now triggers it when the player walks through the doorway.
Clue Change
I moved the clue into a vent so the crouch has a use. Picking it up now shows it on the evidence board.
Evidence Board Change
The evidence board now has to be interacted with on a wall. In the test level, the player needs to find clues to make deductions on the board allowing the NPC to be confronted. The board visuals are a bit more vibrant but still placeholder. Deductions use the connection system from the first version with some changes that make the text green if a clue has been used and text is displayed after to give context to the player.
To open the board, the player must overlap with it. Interacting triggers the “Evidence Board” event which contains the functionality of bringing it up and another event called “Check Clues” which checks whether a clue should be on the board.
The “Check Clues” event checks the boolean variables that track if clues have been obtained so if any are true they will be visible on the board.
Inspect Body
The body can be interacted with to get a clue that is shown on the evidence board.
The player overlaps with the body to allow interaction. A Flip Flop block is used to toggle inspecting the body. A camera that is overlooking the body and an inspect message are shown when inspecting. A boolean is also used to indicate that the clue has been found.
I made two new events known as “Disable Player” and “Enable Player” which control the player’s visibility and inputs so this doesn’t have to be reimplemented every time it is needed as these can be called instead.
Dialogue System Change
I adjusted the dialogue system so it doesn’t end after each part of dialogue and so dialogue options disappear after being selected. A different greeting is also used after the first time.
I created more branches in the dialogue tree accounting for more variables by using more custom tasks and decorators. The dialogue now tracks if a question has been asked, if it’s the first greeting and if the player has already been greeted. This adjusts the dialogue accordingly for each state.
Quality of Life Changes
The crouch key was changed to C instead of Left Ctrl. The perspective change was removed because it was unnecessary and requires time to finetune which is better spent on important mechanics. The evidence board now tells the player if they have no clues. The project was migrated to Unreal Engine 5 so the team could use the newer features.
Black and White Visual Style Testing
I tested the visual style from our research using post processing effects which was toggleable via the Enter key. Everything was made black and white using a post processing material that desaturated the world but specific things were intended to still be in colour.
Adding specific functionality to the material allowed any mesh rendered with a custom depth pass and stencil value of 100 to be in colour. Lower values would still allow colour but it would be partly desaturated with the intensity based on how close the value was to 0.
References:
Laley, R. (2020) Unreal Engine 4 Tutorial – Advanced Dialogue Pt.1 – Interaction [Video]. Available online: https://youtu.be/3uW7CgmrKAo [Accessed 10/10/2022].