To increase immersion I added footstep audio to the walking animations timed to when the foot touches the ground. I added audio feedback to the clue and deduction systems so the player would better understand what is happening. When a clue is obtained, a writing noise plays. If a clue connection is right or wrong, a specific noise will play to tell the player what the result was. The success and fail noises were the same noise that I differentiated using Audacity.
I added a sound for the page turning triggered when either arrow in the journal is pressed to make the journal more interesting.
I implemented the gunshot noise into the cinematic that another team member made.
Game Optimisation
The final game was struggling with performance because of the moving water having dynamic shadows enabled on it. I removed them and the performance stabilised to a consistent frame rate. We also aimed to make use of Nanite to better our performance but virtual shadow maps were not enabled in our project which is required for Nanite so I enabled that to also get a small performance boost from Nanite.
I decided to add a grab animation before certain objects were picked up to make it more engaging for the player and to add to the indication of something being picked up.
The animation was sourced from Mixamo (Taking An Item And Examining It) and imported into Maya along with the Detective model to make it easier to visualise intended changes. Once it suited what I needed, I removed all of the Detective model but one of the arms and imported it into Unreal. The arm was attached to the camera so the grab would always be aiming towards the object the player was looking at.
Grab Arm
I added an additional branch block to the interaction functionality checking if a new Object Interface was implemented in the interact actor. This Object Interface is exclusively used to determine if the grab animation should play for an actor. If the interact actor does have this interface, then the grab arm is made visible and the animation is played. After 1.2 seconds, the arm is hidden and the Interact Interface function is called.
Grab Functionality
The grab worked fine but it slowed down the game when collecting clues so in Unreal Engine I changed the rate scale in the asset details to 2.0 which doubled the speed of the animation.
I added some new blocks to the grab functionality that hid and unhid the right arm of the main model so the character didn’t have two right arms when grabbing. I also adjusted the delay to last 0.3 seconds which matched the sped up animation.
Grab Functionality Changes
Line Trace Detection
The way the interactable object detection worked behind the scenes was a little clunky so I decided to change how it from using a box collision overlap to a line trace hit. A crosshair was also added to indicate when a hit was happening. The video includes debug lines to represent the line trace to better demonstrate the change.
The line trace starts at the center of the camera and ends at a distance set by multiplying the forward vector of the rotation and adding it to the location. This can be adjusted by changing the value the forward vector is multiplied by. Using a break hit result block allows me to set the Interact Actor variable to whatever actor is being detected if it has the Interact Interface.
Line Trace Functionality
Originally, there was an issue with the doors in which the player could overlap with the wrong box collision under specific circumstances causing the door animation to be wrong or change abruptly to moving the wrong way. The line trace change fixed this as the detection is a lot more precise stopping any potential issues like it.
To detect which side of the door the player was facing an additional part was added to the line trace functionality checking whether the component the line trace hit was the front so the correct event for either side could be set.
Door Detection Addition
Inspection Mechanic
To add some complexity to gathering objects, I added an inspection feature that allows the player to look at certain objects. I used the feature with the revolver to hide obtaining a clue behind interacting with a specific part of the gun. The gun plays an animation which I created in Maya by rigging and keyframing the revolver made by one of the 3D modellers on the team.
This mechanic was implemented using a tutorial series by Matt Aspland shown below.
Interacting with the revolver actually hides it and sets an invisible skeletal mesh in front of the player’s camera to the same mesh and makes that visible. A new boolean named Inspecting? is then set to true as well as the player look and move input being disabled. The specific part of the gun is detected via a hidden sphere collision. Interacting with that for the first time plays the animation and sets the clue as being found while the second time hides the inspect mesh, reenables all of the player input and destroys the revolver actor as it is no longer needed.
Revolver Clue Blueprint
The inspection allows the player to rotate the revolver by combining the axis value of the X and Y inputs of the mouse (with a multiplication adjustment of -1 to make it feel smoother) with the relative rotation of a component that the inspection actor is attached to and then setting the relative rotation of the component to the combined value with the mouse inputs as the starting events.
Inspection Player Input
To focus on the inspect actor, I decided to add a translucent background that also blocked the line trace from being able to interact with anything behind the inspect. This was simply achieved by adding a cube behind the inspect actor in the player blueprint which only appears when the inspect is happening.
Wardrobe Interaction
Using similar functionality to the doors, I implemented the ability to open up the various wardrobes throughout the boat level. This would allow items to be hidden within the wardrobes.
The hidden room wardrobe was changed to make use of this mechanic by having a secret door at the back of the wardrobe that could be opened once the player is given information. The secret door is still opened using a level sequence as there were some issues using the timeline method in which the rotations would not work how they were supposed to.
Lockpicking Mechanic
To diversify the gameplay a little more, I added a lockpicking minigame to some objects. The player must first find a lockpick (which uses the same blueprint and functionality as the keys) in order to open locked containers and find certain clues. The lockpicking minigame is displayed in the UI using a scene capture of the assets spawned out of the map.
I created this mechanic following this tutorial series by Ryan Laley using found assets from SketchFab.
The lockpicking blueprint is spawned when the player interacts with a object that can be lockpicked. When it’s spawned, the crosshair is hidden and input is enabled for it while being disabled for the player character. A blueprint block is also used to hide the environment behind wherever the lockpick blueprint was spawned and then the “Generate Lock” function is called. The inputs used for the lockpick are the forward (W = 1 S = -1 and right (A = -1 D = 1) movement keys (WASD) which allows eight different combinations for unlocking. The inputs are made into a rotator that sets the relative rotation of the lockpick on tick. If both inputs nearly match the generated lock positions then the lockpicking input is disable and a timeline is used that rotates the lock to show that it’s unlocked. After the timeline, the player character input is restored and the lockpicking UI is hidden allowing the lockpicking blueprint to be destroyed as it is no longer needed.
Lockpicking Blueprint
To generate the unlock positions, a random integer between -1 and 1 is generated for the X and Z variables that put together will make one of the eight possible combinations.
Generate Lock Function
Game Introduction
I implemented the intro of the game in the bar area above. The only mechanics used are the dialogue and journal mechanics. Each character in the bar has a dialogue tree that reacts to the different states of the intro investigation.
Modular Clues
I adapted the original functionality of the clues to work modularly under one blueprint. This was because the way I originally did it required a lot of repeated functionality because of slight differences. To do this I added a new public text variable named “Other Clue Needed” which could be changed for each instance of the clue blueprint. I also optimised the blueprint a little as there were some unnecessary inclusions before as only the first clue would need to be checked on the second press.
Modular Clue Blueprint
Shown is an example of the variables that need to be set when a clue is added to make the deduction functionality work.
Modular Clues Test Implementation
Journal System
I first adapted the existing journal that was a remnant of the evidence board and changed the visuals to better match what it was supposed to be. The clues were all readded using the modular clue system.
I added an “Inventory” part to the journal that displays everything that is added to the string array that acts as the player’s inventory. I also started implementing the character profile part of the journal which will include backstory for each character as well as the clues that relate to them. Every time the journal is opened, an event called “InventoryReset” is called.
This event clears the inventory section and puts every string in the inventory array as a child of the inventory box using another widget as a base for them. It is called every time the player opens the inventory but it will only have a visible impact if the player receives a new item.
Inventory Reset Event
This journal was made partially using this tutorial series by Darkfall.
I added a profile for the player character which contains the inventory and implemented the rest of the characters. The player can only see the player character’s and the victim’s profiles at the start but as they progress to the main part of the game the rest of the profiles can be accessed.
To toggle between pages I used a block that has executions based on the value of an integer. This integer would be used as the page index and it would either increase or decrease based on which arrow was pressed if possible. The integer was clamped between 0 and 5 as there was only six pages needed for the journal. Each execution for 0 to 5 shows the correct page and hides the other page or pages that it could have previously been on. The arrows are hidden if they can’t be used to go to another page also.
Page Turn Functionality
When the arrows are hovered over they display text to show that they are clickable as well as giving extra feedback to the player.
Arrow Text Functionality
I created an event called “GotClue” to show when a clue has been added to the journal. It shows a UI element of a book and pen for a second before it gets hidden.
Got Clue Event
To make the readability and visuals better for the journal, I changed the font asset to another one already imported into the project by another team member and also implemented a book cover asset behind the journal sourced by the same team member. I also added the place where each character stays so the player would be able to find relevant NPCs easier and added a clues section in the player section for miscellaneous clues.
Final Gameplay
To add the effect of the boat moving, I used a level sequence that moved the environment around the boat that loops by resetting when it gets to a certain point.
I added another NPC to the intro that gives an additional clue.
To progress the game the player has to get most of the clues in the intro and then speak to the captain.
I added clues that serve to give information to unlock either new dialogue or hidden areas.
To improve on the aesthetic of the murder, I used a Megascans blood asset from Quixel Bridge.
Murder Victim
I added NPCs with different purposes in this section. Some NPCs can be asked questions with more options based on the information you have while others are there to assist the player by hinting what to do or to give the player an item to progress.
I adjusted the suitcase so that it needed to be lock picked and so it had a clue that made a bit more sense narratively. I also added the trunk into the hidden room so that the gun was hidden in it.
References
Aspland, M. (2021) Inspect And Rotate Item | Inspect Item Part 2 – Unreal Engine 4 Tutorial [Video]. Available online: https://youtu.be/q62hIj9sHi0 [Accessed 06/05/2023].
Darkfall (2020) Unreal Engine 4: Part 7 – Journal / Notebook [Video]. Available online: https://youtu.be/pNVopBqZ_W4 [Accessed 15/05/2023].
Laley, R. (2022) Unreal Engine 5 Tutorial – Lockpicking Part 1: Lockpick Actor [Video]. Available online: https://youtu.be/sJH4qXqA77k [Accessed 09/05/2023].
mixamo (N/A) Character Animations [Asset Resource]. Available online: https://www.mixamo.com/#/ [Accessed 06/05/2023].
Animations Used:
Crying (Crying and Rubbing Eyes) Idle (Female Idle) Sitting Idle (Sitting Still In A Chair) Standing Idle Taking An Item And Examining It
One of our team members added a character model for the player. This meant that the character needed new animations so I used animations from Mixamo to replace the crouch, walking and idle animations. The crouch mechanic was also changed so that the camera was attached to the skeleton. Although this added some jitter to the camera it got rid of an issue with the old crouch mechanic which was that the camera was able to move to the standing position while the character was still crouched as it had no collision check.
The way the character interacts with the different mechanics was adjusted as well. This was because the way it was set up had a boolean for each thing that could be interacted with which would make the player blueprint bloated with unnecessary blueprinting. To fix this I used the “Interact Interface” method from the NPC interaction and applied it to everything that could be interacted with removing the need for the different booleans telling the player blueprint what was being interacted with.
Player Interaction Change
NPCs
I added four NPCs that each have their own dialogue tree that reacts to each stage of the investigation into who killed the host. Once the player solves the case and informs them they will have an animation reaction that differs depending on whether they were involved in the murder. Innocent passengers celebrate and the culprits get angry. This is a temporary inclusion just to show that the case is solved.
Wardrobe
To hide one of the clues in the level I used a wardrobe that covers a hole into a secret room. The player can’t do anything with the wardrobe unless they talk to one of the NPCs. That NPC will say they heard noises and this will allow the player to move the wardrobe. The wardrobe is moved using a level sequence.
Playthrough
Playable Prototype 2
Feedback
Feedback on the playable prototype resulted in some changes to the existing mechanics and the addition of a new mechanic. The evidence board was a bit tedious as it required the player to walk back to the start room each time they wanted to use it. This was changed to being accessed by pressing Tab on a keyboard instead. The dialogue system had a bug which required the player to press the Left Mouse Button more than once to progress the dialogue so an alternative next button was added to the dialogue UI that would also progress the dialogue. A door mechanic was also requested to be added to the game.
Door Mechanic
The door system was set up to be very modular so that every door uses the same blueprint. This includes locked doors and normal doors. Locked doors require a key to be obtained first which is added to a string array called “Inventory”. After some feedback, the doors were also made to open from either side.
When the door is interacted with it checks whether it is locked or not. If it is not locked then the “Open Door” event will be called. If it is locked then the player’s inventory will be checked for the right key. If the player has the key the door will be unlocked and the “Open Door” event will be called. If not the player is told they lack the key.
Door Interaction
To determine which side of the door should open, there are two collision boxes (one for each side) that can be overlapped by the player. When one of them is overlapped, the other one has their ability to generate an overlap disabled and the end location of the door animation is set.
Door Side Check
The door opens using timelines and rotator lerps which sets the relative rotation gradually as the timeline progresses. There is a timeline for the door opening and closing.
Door Functionality
When the player stops overlapping with either of the collision boxes an event called “Reset” is called. This reset event allows both collision boxes to generate overlap events again if the player is now on a different side of the door.
Door Reset
Suitcase
I added a suitcase that contains one of the major clues in the storage area of the boat. It requires a key to be able to open it. When the player opens it, a level sequence plays that shows the suitcase opening and being rummaged through to find a syringe filled with poison. A clue is then added to the evidence board.
Playthrough
References
mixamo (N/A) Character Animations [Asset Resource]. Available online: https://www.mixamo.com/#/ [Accessed 10/2/2023].
Animations Used:
Breathing Idle Crouched Walking Crouch Idle With Axe Male Cheering With Two Fists Pump Male Crouch To Stand Sitting and Impatiently Waiting Standing Angrily Standing Death Left 01 Walking Backwards Walking (With a Swagger Closed Fist)
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.
Crouching Mechanic Demonstration
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.
Crouch Functionality
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.
Clue Mechanic Demonstration
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.
Clue Blueprint
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.
Display Message Function
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.
Dialogue System Demonstration
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.
NPC Detection
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.
NPC Interaction
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.
NPC AI
End Dialogue Event
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.
NPC Functionality
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.
Dialogue Tree
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.
Perspective Swap Demonstration
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.
Perspective Swap Functionality1
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.
Perspective Swap Functionality 2
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.
Evidence Board Functionality
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.
Clue Functionality
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.
Clue Hidden in Vent Example
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.
Evidence Board Interaction
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.
Check Clues Event
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.
Body Interaction 1
Body Interaction 2
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.
Player State Events
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.
Restructured Dialogue Tree
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.
Post Processing Material
References:
Laley, R. (2020) Unreal Engine 4 Tutorial – Advanced Dialogue Pt.1 – Interaction [Video]. Available online: https://youtu.be/3uW7CgmrKAo [Accessed 10/10/2022].
We used various different communication methods while developing our project and the early prototype. This was to make sure every member of our team knew what they had to work on in these early stages as well as discussing the work we would have to down the line. Our main method of communication was Discord as we created a discord server specifically for our project. However, we haven’t regularly used this as we were working on the prototype or early design work. When we get into full development, this will be fully utilised as it will help us keep track of the progress of each member more effectively.
Examples of the Channels in our Discord Server (Subject to change)
Despite not using the Discord server prominently, we used direct messages on Discord to give feedback on parts of out project. A specific example is feedback I received on the player walking speed within our project prototype as the player was quite slow which could impact the player’s enjoyment.
In this early stage, we used Google Drive and in person discussions to develop our ideas for the project. Google Drive was useful as it allowed to create documents to make sure all members of the team knew what the project idea was, have an early idea of the assets we would need and know what our plan is for the weeks ahead. Max (Level Designer) and I were the main contributors to the Google Drive documents with the other team members adding some input for parts of the documents. When we were together at University we would discuss parts of our project as well as the early pre-production work we were doing.
Our Google Drive document that outlined our proposal so each team member would have consistent information.
Microsoft Teams was another communication method we used. It was mainly used to communicate to our lecturers and to clarify any questions we had about our project proposal. To communicate within our team we didn’t really use this as our other communication methods were already acceptable for what we needed.
Asset List:
Using Google Sheets we made an early asset list for the 3D modellers. This allowed them to assign these models between themselves so they each had an acceptable amount to create. The models were put into different phases to describe their importance with Phase 1 being the most important models and Phase 3 being the least necessary. Although models didn’t need to be completed at this stage, some of the models were created to test different visual styles and to warm up the skills of the 3D modellers.
Project Plan:
We also made a Gantt Chart using Google Sheets to show an early plan for how our project should progress after we have finished our proposal. The different roles within our team have different colours on the chart and it is separated into three sections representing the full development stage, alpha stage and beta stage. Max (Level Designer) is shown in purple, I (Programmer/Blueprinter) am shown in green, Lachlan (UI/UX Developer) is shown in blue and the 3D modellers (Cameron and Jack) are shown in orange.
This video shows the player finding a clue and how it is added to the board.
This image shows the event in the blueprint that manages the visibility of the evidence board UI and whether the no clues message should be displayed.
This video shows the player crouching to explore a vent resulting in the player finding a new clue.
This image shows the event in the blueprint that is responsible for checking what clues the player has found in the prototype.
This video shows an early version of the dialogue system with multiple dialogue options.
This is an example of how the dialogue tree is structured within Unreal. Although this is only a part of the dialogue tree above it shows some of the conditions and checks that are involved in the dialogue.
This video shows the player making deductions by connecting the pieces of evidence together. This unlocks new clues and dialogue options. It is a simple iteration of the system for the moment as it was just to show the basics of how the mechanic will function. This system will be further developed to be more complex as the project continues. These images show part of the deduction blueprinting. This part controls the selection of the first clue and determines whether it is clicked first or second and if it connected to the right clue.This video displays the changes that occur in the dialogue when the player has spoken to the NPC more than once and when the player has the clue.
This image shows the events responsible for enabling and disabling the player in the blueprint when the player talks to NPCs as the player could be in a position that would block the dialogue camera.
Prototype Playthrough:
This video shows a full playthrough of this prototype.
Feedback Changes:
Our early control scheme had the E key serve as the interaction button for the actions the player could do and the left mouse button was used to click on dialogue options. A bit of feedback we received was that these two controls could be combined. There was no important reason why this couldn’t be the case so in our project currently the left mouse button is used for both.
One bit of feedback received from testers was that there was no indication to the player on the evidence board that the player hasn’t collected any clues. To rectify this a message now appears before the player has found any clues. In the final project, this may be indicated in a different way but for now this does the job.
Originally the idea was to have the game mainly in first person with a third person perspective when the player was travelling between crime scenes. However, when the game scope was lowered to being just on the boat it was causing a lot more visibility issues than it was worth. Feedback was also received on this feature saying that it was unnecessary and added just for the sake of it. This feature is shown below but it has been cut from the game.
Our original idea was to have the game start on the boat and for this murder mystery to be the tutorial for a game with multiple crimes to solve. However, pretty early we decided to downsize our idea so that it the game at least majorly took place on the boat. This allowed us to keep our scope pretty feasible to make in the time we have available.
I made a mind map of the gameplay mechanics we had ideas for at this stage. As these are implemented into the prototype or main project I will be able to determine how feasible these are to make. This allows me to make any adjustments to their intended implementation or replace them with a mechanic that can fulfil the same role. I can also determine any mechanics that aren’t necessary for our project.
To allow us to work on the prototype and later the full project as a team, I set up a GitHub Unreal Engine project. This allows us to work on separate computers while still contributing work to the same Unreal project. This saves time later in development as otherwise one of our team member’s would have to compile all the different parts of our project into one project which could prove quite tedious and mistakes could be made that only the respective team member’s could fix easily.
In the early stages of our project, while we were still figuring out our ideas we did some research into different media that would assist us in developing our ideas. Below I have separated the inspirations into some that are more generally for the project and my personal inspirations for the project.
Project Inspiration:
The Return of the Obra Dinn (Game): This game is quite influential in the direction of our game as it truly allows the player to actually figure out mysteries on their own. The specific use of the journal and its assistance in figuring out each of the deaths on the Obra Dinn is something that we will adapt for our game as we will implement a journal that contains notes on information the player finds throughout the game. We will also take inspiration on is how you can only guess when you have enough information and how the game never explicitly tells you whether a deduction is correct as we want to implement something similar within our game but not necessarily to the same extent.
The Return of the Obra Dinn Screenshot (Webster, 2018)
Sin City (Film): The visual style used in the movie Sin City is quite similar to the idea we had for our visual style as it also is mainly black and white while highlighting specific colours such as red. This is why we are using this as inspiration for how we can implement the visual style. The usage of highlighting specific colours could be used to draw the player’s attention to important objects and areas in the environment like how in the movie they use the mostly black and white colour scheme to provide emphasis to specific things.
Sin City Image (inspiraze, 2017)
Mafia 2 (Game): Mafia 2 is set in a similar time period to our game idea so the aesthetics of both characters and the environments are good inspiration for how our game could look. It can also serve as inspiration for how some of the character’s could act to match the time period.
Mafia 2 Screenshot (Wald, 2020)
Batman Arkham Asylum (Game): Batman Arkham Asylum as a game has multiple things we can draw inspiration from. Although the actual detective parts of the game are quite limited due to that not being a primary focus of the game, the way in which the player examines the environment in certain parts of the game can serve as inspiration for when we look for clues in our project. However, our implementation would be a lot less technological and would make it a lot less obvious. The way in which certain collectables are placed is another bit of inspiration for our gameplay as we aim to hide clues in hidden places. The UI within the game also served as inspiration for how some of our UI could potentially be implemented as it has a very stylised look.
Batman Arkham Asylum Screenshot (Saint Aaron, 2015)
Personal Inspiration:
How to make a good detective game – Game Maker’s Toolkit (YouTube Video): This video is very insightful on how to implement detective mechanics into our project without making it explicitly obvious what the right thing to do is. Using this as inspiration for how we structure our game will allow us to make the player feel like they are actually a detective rather than just being able to guess the correct sequence of events. This video is especially important as a lot of the game inspirations we have handhold the player in some ways with their deductions so keeping this in mind will help us to not help the player along too much.
What Makes a Good Detective Game? (Game Maker’s Toolkit, 2017)
A Hand with Many Fingers (Game): This game is about the player putting together a conspiracy with the files they can find within an archive. It serves as good inspiration as it utilises an evidence board as a primary mechanic which is something we wish to include in our game. However, the way the player searches through files to uncover clues that may connect to the clues they already have so they are able to make deductions is another thing we can take inspiration from while developing our game.
A Hand With Many Fingers Screenshot (Colestia, 2020)
L.A. Noire (Game): As this game is also a detective game it can serve as good inspiration for how to implement some of our mechanics. The acquisition of clues within the various environments is a good thing to take inspiration from as the player can pick up and examine a variety of objects with some being completely irrelevant. This is good for our game as only being able to interact with the important objects would make it so the player can find the clues pretty easily. The way the player examines the objects is by rotating them or interacting with them in some way to get a clue from them which if implemented into our game would add more player input in the gathering of clues. The dialogue system in L.A. Noire allows the player to question suspects using the relevant clues they have gathered and then choose whether: they think the suspect was telling the truth, they doubt the suspect or if the suspect was telling a lie. The usage of relevant clues is good inspiration for our game but the second part of the dialogue system makes it that most of the time you know you have to question the suspect’s testimony. In our project, we would like to make it less obvious whether the suspects are misleading the player.
Our project is a murder mystery game on a boat at the turn of the 20th century. It will be developed on Unreal Engine 4. The aim of the player is to solve the murder before the boat is able to dock. From a first-person perspective, the player will explore the boat to find evidence and interrogate suspects to determine which passenger may be the killer.
My role:
My main role within our project is programmer/blueprinter which means I am responsible for getting the main systems and mechanics within the game to function. I will start by determining what mechanics we are going to need and then getting these mechanics to work in a test prototype. I can figure out any issues that need to be fixed as well as adjust how they work if feedback from testers deems it necessary to do so. I will be the one implementing most of the gameplay scenarios that are designed by our team. As the story progression comes together, I will be able to use the mechanics I already created to put the game together as we further develop it.
Genre:
Our game’s genre is noir detective thriller. This matches our project as we want to create suspense as the player tries to deduce who the killer is. Each character will be morally ambiguous and have their own motives for potentially being the murderer.
Setting:
The game will take place on a paddle-steamer travelling the swamps of New Orleans known as the SS Arctic. This limited environment allows us to make our game feel a lot more close-quarters to make the urgency of finding the killer higher. It also make the scope of our project more manageable as focusing on one environment will allow us to improve the quality of our end project.
Story:
Detective CC Tinsley by complete coincidence finds himself embroiled in a murder mystery while on a journey across the Mississippi onboard the SS Arctic as the host of a gathering of old “friends” dies under mysterious circumstances. He must determine the exact events behind this tragic occurrence before the boat reaches its destination as he is the only passenger with no links to any of the other passengers including the murder victim.
Characters:
The characters we aim to include in our game are listed below. We wish to have a range of personalities and backstories which will be fully determined as we start fully developing our project. This will also allow the rooms of each character to be visually distinct and have unique items related to them.
CC Tinsley (Player Character)
Captain Luce (American)
William Eubanks (American)
Fernand Lacroix (French)
David Kirkwood (British)
Irene McAllister (British)
Lillian Brown (American)
Mr Watanabe (Japanese)
Franz Haber (Prussian)
Gameplay Mechanics:
As part of our proposal we outlined some basic mechanics that we could have in our game. Part of my role will be determining the extent of these mechanics and how they will be implemented.
The game will be at least mainly in first person with the character having the ability to walk and crouch.
Crouching will allow the player to find evidence in more hidden areas.
There will be a conversation system in which the player can question the NPCs with various dialogue options which will also allow the player to challenge their account of events.
Clues the player finds may not be immediately useful and may require further inspection to find their relevance for example rotating them to find some more information.
The evidence the player finds will be displayed on an evidence board which allows the player to make deductions by connecting these clues together.
The player will have a journal which makes notes on information the player receives whether its directly relevant or not.
Puzzles could also be included in our game to find information such as safe cracking or rearranging paintings but this is not a high priority inclusion. It may also clash with our game style if it not implemented in a way that is believable in our game world.
Visual Style:
While in the concept phase for our project, we had a very strong idea for what our visual style would be. This was a black and white style but specific colours such as red would be in full colour. While not a completely original idea, we thought this would be a great contrast as well as really complementing our project’s genre. This could be applied by using a filter within Unreal Engine to make most things appear black and white. While further developing this idea, we brought up the idea of it not being fully black and white but the filter being tuned down a little so there is some semblance of colour but the colours would be very moody to still match our game’s atmosphere well. We will fully determine the visual style after experimentation within our Unreal project.
Audio Considerations:
Although none of our team members strengths involve audio we still wanted to take some audio considerations into mind as audio can be really important in creating the feel of the game. Some examples of audio we determined as being important to our project are:
⦁ Ocean sounds/rain
⦁ Boat sounds, engine, creaking etc.
The inclusion of these help to immerse the character in the setting as a lack of these sounds would make it less believable.
⦁ Atmospheric background music
Including background music would help to set the various moods and feelings we want to create throughout our project.
⦁ Crowd muttering
⦁ Character voices/mumbling
These would help to make the environment feel more alive as the environment wouldn’t be completely silent with passengers and staff on the boat especially after a murder. Giving the character’s voices would also improve the player being able to discern the feelings of the characters.
⦁ Jazz or appropriate music.
This music will be mainly used on the main menu so it has to introduce the player to our theme and it matches the time setting of our game well.
⦁ Footsteps
Adding footsteps for the character will better immerse the player in the game. They will change depending on the material the player is walking on to increase the immersion.
