Starting fresh using Unreal, the development for this project was to try and achieve what could not of been done within Unity. Additionally, using a new Engine with minimal to no experience using, would make this more challenging to accomplish. However, this felt like an accomplishment that could be made if the mechanics were similar to those the project was inspired to have.

Knowing a method to implement the mechanics, progress began within Unreal.

Unreal Engine project - Creating the Ai:

Before developing any scripts, the model created for the initial project would need to be imported and set up. A fellow peer helped make sure the model designed initially could be compatible and work inside of Unreal Engine whilst also checking to see if the skeletal mesh and the animations for the movement worked.

Then, adding basics such as PawnSensing, AIPerception, as well as some visual improvements to make the Ai function the way it was envisioned for the Unity project. 

Once the Ai's base model had the basics it required, creating the scripts was next.

The first step towards making the mechanics the project aimed to have, was to re-create a random roaming Ai. This was going to be a new task that had not been done before from prior experience as the previous Ai that has been developed. This is because the Ai that has been made previously relied on following a strict point or pattern, whereas the Ai for this project would choose it's own navigation.

Additionally, the Ai inspired for this project would have the ability to cycle between different audio (such as the standard theme, to chase). 

Using the Tick Event and assigning some Boolean Variables (such as investigate, seePlayer and Caught?), to ensure the first section of the Blueprint would work. The process is;

 As the Tick Event would begin, it would connect to a Branch. This Branch would have the Caught? variable as false and would then connect to a Sequence. If the outcome was still false, the Ai would then run a Delay for a period of time before choosing it's next point to roam to. The distance the Ai could move was assigned by Random Float in Range, to allow easy customization on how much it could move around. 

Furthermore, assigning the GetActorLocation as this would be required to check where the Ai was and connect to the next section of the Blueprint. 

Finally, the OR Boolean function allows multiple Booleans to be used to run different actions and/or if multiple Booleans are required for a singular function. So if the Ai could not see the player and is not investigating, it would just continue roaming.

The next section of the sequence would be connected to another Branch which checks if it still cannot see the player, to continue a new function which was for the audio. The function being; that if the Ai was roaming, the normal background theme would play. 

Continuing, the GetActorLocation was connected to the GetRandomReachablePointInRadius. This would allow the Ai to choose from the range provided to it, how far it would want to move based on it's restrictions. If the OR event is false (as in the Ai could not see the player or is not investigating), this would connect to a new Branch to set the Ai's moving Boolean to true. 

This allowed the AI Move To, to run.  If this succeeded, it would then set the isMoving? Boolean to false and would run a debug message stating 'aimlessly roaming'. This made it easier to tell if the Ai was actually moving around as intended. 

For the sounds to play, a Timeline was needed so that the transition of the different themes felt they changed faster. The length was set to 5 (for 5 seconds) as this felt like a good length of time to adjust how high/low the theme could ramp up and down. 

These values would connect to the corresponding Set Sound Mix Class Override so that the correct sound that should play based on what was happening would override the other, making the other sound stop playing. These connected to a Push Sound Mix Modifier that was created to cycle these sounds and linked to another print string to show the audio going back to normal.

This meant that if the enemy was no longer chasing the player (or had not chased the player), it could change the theme corresponding to the action currently happening. However, this was not yet finished as the rest of the script for chasing the player was required. 

Using an Event from the PawnSensing that was assigned, it would allow for the Ai to Cast To FirstPersonCharacter which was the default character class used for the player. This would allow the enemy to begin sensing specifically for the player character within the world and if they got within the sensing radius, it could begin the chasing Blueprint. 

Linking this to a Sequence. This would allow the Ai to switch between; chasing the player and switching back to not able to see the player. If it could not see the player, the Ai would run a Delay and check again if it could still see the player, before linking back to a random roaming state. This meant that it gave the Ai a few seconds to continue chasing the player if they went around a corner so the Ai would not immediately lose interest. 

If it has seen the player, then it would begin chasing and move towards the player's position. 

As the Ai would move towards the player's new position, it would run a Custom Event known as Catching Player. This would be used for if the Ai had caught the player, to end the game. 

These events were tied to a Do Once so that it would not constantly repeat so that both the Game Over and the reset roaming event could transition. If the Ai was still chasing, new Set Sound Mix Class Override's were linked so that the chase theme could run and change back if the Ai was no longer pursuing the player. 

A print string was used to check if this was working and if the Ai was chasing the player.

Unreal Project - Play chase audio:

To make sure all the audio worked as intended, several Sound Classes were created to help assign them to the Ghost so that the correct audio would play within the Mixer and the Set Sound Mix Class Override's. 

Additionally, creating a simple Blueprint for this so that it could be called across other Blueprint classes. Having these link to the Audio Mixer would mean that they could be rendered across multiple platforms, feature parity across multiple platforms, as well as contain backward and forward compatibility features. Meaning, using a Audio Mixer would make the sounds work and flow much easier even after the level/s get updated or new content gets added to the project.

This Blueprint was linked to the other Blueprints that used the Set Sound Mix Class Override events so that they could all be called accordingly. Using a Timeline so that these could all ramp up and down naturally. From this, the Ai's main Blueprint class would be updated for the chase to work.

Another Blueprint within the Ai was made so that the Chase theme would run properly as and when the player was being chased. On the Event Begin Play Event, it would run a Sequence to; by default play the main background ambience and if the Ai was Cast To FirstPersonCharacter, to then play the chase theme. 

This was done through a Play Sound 2D function, that allows a selected Audio Source to play at the location assigned. Although it played the ambience and would also transition to the chase theme, it was also supposed to play the Tension if the player got toop close to the enemy. 

As the Tension was not being checked, this would be something to fix later as it was not necessarily required for the demo. Making sure the Cast To FirstPersonCharacter was set so that the chase theme and the other audio would play. 

After the Play Sound 2D were all assigned audio, these were connected to the Set Sound Mix Class Override functions so that they were linked to the other Blueprints. Finally, a Push Sound Mix Modifier was included so that the Ghost Mixer would play these sounds at the correct moments.

Here is a video demonstrating both the roaming, chasing and the audio working:

Unreal project - Ai Game Over:

As mentioned above, a Custom Event known as Catching Player was assigned to this Blueprint so the Game Over could function. It also used another Custom Event called Rotate_loop which would be used to display when the player had been caught that they would face the enemy before the game over transition began. 

This felt like a simple but effective way to display to the player that they had been caught by the enemy and had lost the game. 

Setting up the Caught? Boolean as true, it would Cast To FirstPersonCharacter and would check within a Branch if this was true, it would then run the Rotate_loop Custom Event. Additionally, assigning the object as a Get Player Character and promoting the Cast's variable to As First Person Character. 

This then would connect to GetActorLocation, allowing the player to then rotate based on a value set. 

From the Branch, it would have a very short Delay so the rotation event would be almost instantaneous. Furthermore, using a RInterp To, would allow the targeted reach rotation on the current rotation, have a more smooth rotation effect. This meant that an animation would not be needed to show this effect.

Linking RInterp To into the SetActorRotation, making sure the Target was the First Person Character and the New Rotation was the values given to the RInterp To. To ensure this rotated as smooth as possible, another RInterp To was used, however it was linked to the Get World Delta Seconds. Meaning the values would be synced between both how fast the player would rotate and multiplied by the values of the frames per second. 

Finally, this would link to a Set Control Rotation so that this could be assigned to the Custom Event Rotate_loop.

For the Rotate_loop event; 

- It would only Do Once to ensure this game over would not be continuous and the player would be stuck rotating towards the enmy over and over. 

- This is then linked to a Sequence to check if the player was not caught that it could reset for the next time the player would be caught after the game over happens.

- If the player was caught, there would be another short delay, before beginning the camera fade function. 

- The camera fade function had yet another delay so that the fade in and out felt more natural. 

- Finally, converting a string to a name value, the current level scene could change back to the same level but at the beginning. Creating an automatic restart like effect. 

This can be seen here:

With the general audio now working and assigned correctly, the first proper mechanic could be implemented within the game project. 

Unreal Project - Hiding Mechanic (first mini game mechanic):

This mechanic would be to allow the player to hide from the enemy. This would add more adrenaline and give the player a sense of powerlessness against trying to stop the enemy, because the enemy was a ghost and therefore could not be defeated. However, before any scripts could be made for this, a model for an object would be required so that this mechanic could be implemented properly.

Once a free model was sourced, the beginning set up for the hiding Blueprint could be done. The purpose of this Blueprint was; if the player interacted with this locker and pressed the correct key, the player would transition inside of the locker and hide from the enemy. 

The Hiding Binding was set to H as this felt like a relevant key bind to give the player for this action. Additionally, for the other actions to be implemented for the project like Interact and Throw_rock were assigned to be ready for later.

Within the Blueprints Construction Script, variables were assigned (such as floats and a Boolean) so that when the player interacted with the locker, the lockers door could open/close and allow the player to hide. 

Using a Branch, the isHiding Boolean was set to check if the player was or was not inside of the locker. If the player was inside of the locker, the Set Actor Hidden In Game would be called so that the Ai could not detect the player and would return back to roaming if the player was being initially chased. 

So if the player was not inside of the locker, the opposite would happen, meaning the player would then not be hidden.

If the player was inside of the locker and hiding, Set Actor Enable Collision would be set false so that the player was bound inside of the locker and could not interact with anything inside. This would make it easier to show that the player was trying to hide from the enemy. Again, if they were not inside, the collision would then be re-enabled.

Allowing a reference to be called to the player character, this and a Get Player Controller could be linked to a Set View Target with Blend function. This would allow the player's camera view to switch to the new one assigned inside of the locker. Meaning whenever the player was or was not inside of the locker, the camera view could change.

Unreal project - Hiding, allowing the player to interact (part of mini game/mechanic 1):

With the Construction Script set up, the next task would be to allow the player to get inside of the locker. This would be done by setting a few Events, one for the Hide Input mapping, and using the Box colliders Begin/End overlap Events. Making sure the Begin/End Overlap Events were first assigned to a Cast To FirstPersonCharacter.

This would allow the player character to not just Enable Input but also assign the reference to the character so it can be called and used later. 

If the player entered the Box collider, the player could then start initiating the ability to enable hiding. The Enable Input would be linked to a Gate, where the InputAction would be set in the Enter value, the Begin Overlap  to the Open value and End Overlap to the Close value. 

A Gate is a part of flow control and would allow a stream of executions to open and close based on the action. In this case, to allow a player to access in and out of a locker. From the Gate's exit, this would link to a Sequence which would toggle hiding or run the inputs to open the locker door. 

If the Toggle Hiding Custom Event was running, it would then call another Custom Event Moving Lockcamera and begin a short delay. Once completed, it would then loop this so that each time the player would Toggle Hiding it could re-run this event without interference.

For the Open_door inputs;

This would be tied to a Timeline to do a simple transition to open and close the lockers door. Meaning designing an animation for this would not be required. As the intention was to have this open smoothly, the length of the Timeline would be only 1 second and the door would be fully open within half of this time. Giving it a fast and simple transition to open/close the door in front of the player. 

Making sure the lockers door was also referenced so that the values of the rotations could be connected to both a Lerp and SetRelativeRotation. 

Unreal project - Hiding, moving camera inside the locker (part of mini game/mechanic 1):

For the initial script to function, the locker would need a second Blueprint to allow the player to look inside of the locker and allow the Moving_lockcamera Custom Event to be called.  This Blueprint would use InputAxix Events for LookUp and Turn, as this was all of the movement the camera would need inside of the locker. 

Getting the Reference Char variable and the isHiding Boolean, these were linked to a Branch (for both Events). If the Branch's conditions were true, they would be linked to a Set Pitch/Yaw variable node.  

If the Branch's condition was false, this would link to a Add Controller Pitch Input, alongside linking back to the InputAxis Events Axis Value's. This allowed the Input of the Axis to then be Clamped via Float whilst also adding the InputAxis Events Axis Value float + the Pitch/Yaw Floats values. 

The Clamp would allow the restriction of how much the camera could look up/down and turn inside of the locker. This is understandable as a similar process can be used within Unity through clamping the players camera view. After the Pitch/Yaw values were set, the Pitch value's output with be multiplied by -1. Restricting how far the player's rotation was. 

The Yaw and Pitch's new multiplied values were linked to a Make Rotator, which would allow the Moving_lockcamera's Custom Event output to connect with the floats values. The Moving_lockcamera Event is connected to a Branch whilst also containing the isHiding Boolean. If the value is true, it could then link to the SetRelativeRotation node. 

This node is what also connects back to the Make Rotator so that the values of the floats could be called and used in this Blueprint and be linked to the previous. Finally, from the SetRelativeRotation, would have a short Delay which then calls the Moving_lockcamera Custom Event. Allowing the event to be synced between the Blueprints and allow these scripts to function as intended. 

Here is a short video demonstrating this:

Unreal Project - Types of door mechanics (Mini game/mechanic 2):

Like in Unity, having doors that could have unique functionality's would be an essential aspect of the game. There was a few door designs that would be looked at;

- Inaccessible doors (doors that won't open even with player interaction),

- The exit door (how the player will escape the level),

- Push to open doors (ones that were shut and needed the player to push a button to open them).

Most of the concept from the inaccessible door could be carried across for the exit, with some tweaks to allow the player to go through. So development towards these began. Having the exit door be tied to the second mini game mechanic.

Unreal Project - Creating locked doors (part of mini game/mechanic 2):

The doors model was a standard free asset that came with the Unreal starter content, known as SM_Door. This model worked for testing as the door and the doors frame were not attached to each other as the same object which would allow the main door to be accessible once the Blueprint was created. 

Essentially, if the door was still attached to the frame then when the door opened after the players interaction, it would not rotate or open correctly as it was not designed to be decoration like most models that were found. Next, basic float variables for the door to open and close were assigned to this mesh object, alongside a simple Box collision as this was all that was needed for now.

With the basics for the model assigned, the next step was to create a simple Widget so that when the player interacted with the door, a prompt to let them open/interact with it could pop up onto the screen. A simple design for this pop up was made within Illustrator just because for now, it just needed to work simply for demonstration. 

This is the design:

Now that the Widget was created, the Blueprint could start to be made for the door. Firstly, making sure that the relevant events were used; Interaction, Box Begin/End Overlaps, as these would be the Events needed to cast to the players action and show the new Widget when they went inside of the box colliders space.

If the player had interacted with the door, this would connect to a short delay before linking to the Branch that would then check the rest of the Blueprint. As for the Begin/End Overlaps, these were Cast To FirstPersonCharacter as then when the player was within the space, the Widget could appear and allow the player to see it on the screen. This was achieved by linking the Create Widget Interface Widget node to the Add to Viewport. 

Furthermore, if the player was not inside of the box collider, the Widget was top not show onto the screen by removing itself from the default parent node.

Unfortunately, the Widget once it has displayed would not disappear when the player exited the collider. The only conclusion for this was because the method of design for this process was incorrect as it should preferably be used with a Set Visible node instead. However, as this was not a major requirement and more of a desired feature, this would be something that would be looked at later.

Assigning both a Enable/Disable input node to the Begin/End Overlap Events, the sound effect designed for the door would then be played through a Play Sound at Location node. Meaning each time the player opened/closed the door, the doors sound would be displayed at the current actors location (the actor being the door). 

This is where it would be linked to a Gate. Enter would work if the Branch's requirements (the player has a key to open the door and has interacted) were true. The door could also be opened if these were also true. If they did not have the key or did not interact, then this would be false. 

Making sure the Gate was set to Start Closed by default, otherwise these requirements would not matter and they could just go through the door. Linking the Gate to a Flip Flop as this like the Gate, was a part of flow control. How it's used is it will take an execution output (in this case opening/closing the door), and could toggle between two execution outputs. 

These outputs were assigned to a Timeline, so that the basic door opening and closing could be displayed in a smooth and short transition styled effect. Due to having limited experience doing art, Timeline's could be used in this way to give simple instructions for rotations or movements for objects. The values were set to 2.00 meaning it would fully open and close after 2 seconds. 

To ensure that the Timeline worked, the variables for the Door Open/Close that were made at the start were assigned to a Lerp. The Alpha value would be the Timeline's 'Door' float value, 'A' would be linked to Door Close and 'B' was linked to Door Open. It was done in this order as the value for the door being open was '30'. Meaning to make sure there was no complications with the angles and would open smoothly, the values were set up this way. 

These were all then linked to a SetRelativeRotation node so that only the Z (Yaw) rotation would be running. This is because a door only turned horizontally and not vertically. 

Here is a short video showing this all functioning:

Unreal Project - Making the Key (part of mini game/mechanic 2):

The video above shows the Key Blueprint also working with the door, so the next process was to demonstrate how the key functions for this to work. The key's model used was one I found on Fab for free as a place holder for the demonstration. Although 3D modelling skills were a weak point, one of the intentions was to try and create some of the models within the game at a later date. 

Below is the Key's Blueprint.

Like with the Door, the same Events could be used again to allow the player to collect the key. Similar to projects created in Unity, this is a form of collecting mechanic where the player is required to have a specific item such as this key, to do a specific action (in this case, use the key to open a door). 

This Blueprint designed was fairly similar to the doors script but with a slight difference. Mainly being that if the players input opened the Gate, the Set hasKey? Boolean is true to register to the door that the player had the key collected. Once the key had been collected, an audio cue would be heard through the Play Sound at Location to signal the player had picked it up. Once it had been collected, a DestroyActor node would then be linked so that the key would no longer be in the level. This was so that the player knew they had the key and that it was no longer visible.

Unreal Project - Creating the Exit (part of mini game/mechanic 2):

Following the doors Blueprint, this could be duplicated to create a simple Exit. The main changes was the actions that would run after the door had been opened by the player. This was tied to the Game Win mechanic. As the Game Over was already working, there would need to be a way for the player to win/beat the game. 

From the new duplicated door script, the main change was to use the node Get Player Camera Manager. Similarly to the Game Over, if the player opened the exit, the camera would fade out before opening the victory screen. The fade would be tied to a Delay of about 2 seconds to give it enough time to transition. Making sure the alpha was tied to 1 as this was the colour tone that felt best for this as it was the same for the Game Over. 

Then it would Delay again before linking to the Open Level (by Name) node. This would be assigned to the Victory Screen level. Meaning, another level within the project would need to be created for this to work. 

Using another Widget that would cover the level screen so that these prompts would be available to the player. As it stands, these buttons do not function yet as for the demonstration, it would just need to load the level map to make sure the basic functionality worked. 

Here is a short video to show this:

Unreal Project - Drawers (part of mini game/mechanic 2):

Expanding on the second mini game mechanic, having the player search for the key would add more variety and challenge to the experience, rather than just having a key be on a cube and easy to see. Using a similar logic to the door, a free asset for some drawers was found so that the key could be put inside of this and be hidden from the players view. 

Having this would mean the player was not just trying to avoid a constantly roaming enemy, but would be frantically searching around for the key in order to escape. However, unlike the door, this would require a lot more work done as the intention was to let the player open up each individual drawer.

This Blueprint would use two main Events; Begin Play and Interact. This was so that the drawer when the game started could be used instantly and the individual drawers could be opened based on the player interacting with them. Assigning vector variables for the starting and end locations for these drawers was also required so that it knew how far they had to be pushed in and out. 

Once the Event for Interact was linked to the Cast To FirstPersonCharacter node, to make sure the drawers could open in and out they would need both a Get Forward Vector and GetWorldLocation. This would be referenced to the players camera so no matter what angle the player faced the drawers actor, it could still function as intended.

The GetFowardVector would link to a multiply vector by float node. The reason for this was so that the line that checks how far a line is drawn (this line is what the drawers Blueprint references to let the player interact with the drawer from any angle/position). 

Continuing, the reason for using the LineTRaceForObjects was because this would act similarly to a RayCast in Unity. Essentially, having this line drawn would allow the player to easily interact with specific drawers on the object. The value of this line was assigned previously with the GetWorldLocation for this start value and the end value was assigned with the multiply vector by float, linking to a vector plus a vector. For the Object Types, this would be linked to the Make Array and this was set to be WorldDynamic. This meant that the drawers would actually be moveable objects. 

Upon the Hit Component for Break Hit Result, this would then be Cast To StaticMeshComponent which was referenced to the main drawer mesh. This would mean that so long as all the individual drawers were a part of the main mesh, each individual drawer could then be interactable. How far the drawer would go could then be assigned to a GetRelativeLocation from the static mesh. Out of the Rotation for X, the value for how far the drawer could go would be set to the maximum of 30 by a greater than or equal to float. This was so that it would go out by 30 and go back in again by 30.

Linking these to a Branch, the sound of the drawer opening/closing could then be created using the Play Sound at Location node. Two different sound effects were made for when the drawer opened and closed so that the drawers felt they had more dynamic and variety. 

To make the drawers values actually function, the static mesh reference needed to be assigned again and linked to a series of float values for both the Set Start and Set End. For the first Set, the location of the starting locations for x, y and z were the same. This was because the drawers base value would be 0 as it was yet to be interacted. If it was interacted, the x value would then be linked to a float plus a float and the attached to a second Set. This value would then be linked to a Timeline to do a basic transition to open and close the drawers. 

Finally, using a Lerp (Vector), this could link from the Start/End location variables so that the new location of where the drawer had been opened was by 30. This segment of the Blueprint could be repeated again but the main change would just be to make the drawers values go back down by 30 on it's location.

Here is a short video to show this:

As seen in the demonstration, the drawers are still have a few tweaks to be made as the front part of the drawer can also open up by 30. Although it would be a nice fix to implement, for now it was not necessary so the next focus was to expand further on the doors by having doors that could open via a button press.

Unreal Project - Button doors:

Having a door be tied to a button seems simple as a concept, but it's purpose is to slow the player down, especially if they're being chased. If the enemy was pursuing them, they would have to spend a few seconds to press the button for the door to open and they can get into the area.

Assigning new variables to this such as a Transform for the Button, as well as setting the Button as instance editable. This would allow the Buttons values (such as location/position) to be changed within the scene, without it conflicting with the Blueprint. 

To make sure the Button could remain instance editable, setting up the basics for the Construction script was required. All that was needed was to reference the Button static mesh, the new Transform variable and have them link into a SetRelativeTransform. Once this was all linked and assigned, the Button in the level could be moved around freely and should work whichever angle or position it was set. 

Next, the Events needed for the door was to be put in place so that when an input with the Button was called, the door could run it's functions and open. Just like with the previous doors, the Begin/End Overlap and Interact Events were used as the players input was essential to actually press the Button. This was so that any Ai that could be developed or added later had no control on the doors functionality, only the player. 

Once the Cast To FirstPersonCharacter, Get Player Controller and the Enable/Disable Input nodes were linked, based on what was required to open the door (in this case Enable Input) would open the Gate, Disable would close it and the Interaction Event would enter. Making sure that this also started as closed so the door would not just be open upon the game starting.

From here, the Gate was connected to the Button input Blueprint. Using a Timeline and ensuring the Input value was set to Play from Start and not Play. Because the Button was only supposed to run when it was interacted and only during that time. The value for how long the Timeline was only 0.10 as a Button when pressed naturally only goes in a small distance and the pressure from that is instantly released afterwards. This felt more like an accurate value to represent this time frame.

Upon starting, it's default value was -5, as that was it's starting position. Meaning once it had been pressed it would go to 0, before running back to -5. Once pressed, the Play Sound at Location would make the noise of the Button being pressed at the same time as the door opening sound effect. Doing it this way was because when the Button had been interacted, the door would open at the same time, so making sure the sounds were played at the same moment. 

The outputs from the door sound being played, was linked to the rest of the doors Blueprint, which was so the door would open.

This was the Timeline for the Button:

When the output was completed, this linked to a Flip Flop. This would allow the doors Timeline to run the door open/close transitions, based on whether the Button was pressed once to open or again to close. 'A' was to open the door, meaning if the door was opening, the SetRelativeRotation was called so that doors Closed/Opened Angles variables could give this new rotation value. 

Additionally, if the Button was pressed to close the door, then the rotation would change to the opposite value to close the door again. 

Here is a short video demonstrating this:

Unreal Project - Basic level design:

Deciding that now with a bunch of features and mechanics explored, to create a simple level/scene where a bunch of these features could be tested. Using a bunch of free to use assets/meshes to help try to build a simple environment. The scene would have all of the current working features designed, as well as give a more dynamic environment to test new ones out if there was time.

Keeping the level as simple as possible so that it could just be used as a demo to test the mechanics in a more diverse environment and make it feel less of a grey box. 

How it currently looks:

Unreal Project - distract enemy mechanic (still a work in progress):

A feature that was explored was the ability to allow the player to potentially throw a small object (in the example a rock was used) so that the player could lure the enemy aside to increase their odds of survival. However, as mentioned, this mechanic does not currently work yet but is still being investigated. 

Despite this, the principal for what was to be achieved can be shown by the Blueprint designed.

Upon the main First Person Blueprint, a new Input Action was assigned so when the player pressed 'G' this new Event could be used. Linking the rock reference inside of the players Blueprint class to a GetWorldLocation and GetSActorRotation, this would allow the rock that appears from pressing 'G' to link up to the Blueprint class for the rock mesh, known as SpawnActor Rock Distract BP.

This return value would be a sphere (which the rock Blueprint has), which links up to a Set Physics Linear Velocity node. Whilst also connecting the return value from the rocks Blueprint to the new current location. Meaning, when the player first throws the rock, it will appear where the player currently is standing, and it's end location value is multiplied via the vector/float values for it's new max distance location.

With that being assigned inside of the main players Blueprint, the rest of the Blueprint for the rock could then work. For the rock itself, it has the sphere object reference assigned so the players Blueprint understood and could link the two together. 

From this, using a Event Hit Event because this would allow the object to check if it has hit a surface (or other object) within the level to then play the sound of the rock hitting that surface area. Additionally, making sure that Get Player Character was assigned within this Blueprint so the rock knew it was linked to the players actions itself. 

The Branch had only a true condition because if the player had not thrown a rock, then there was no need to create a false argument. But instead, to also have a not equal to Boolean because if the rock was thrown then the output would just be true, meaning the Branch's False output would not need a value as it would check only if the rock is thrown by the player and no other actor. 

Then, to ensure this could be done smoothly, it would be called through the DoOnce node so that each time the player threw a rock, a new one would appear and play their own sound upon reaching the sound location. This would then be attached to a ReportNoiseEvent so that Ai could hear the rocks location if it was near. 

This is a video showing the rock being thrown and playing the sound:

Unreal project - Ai detects rock (still a work in progress):

The Ai's Blueprint is supposed to check if it had heard the rock hitting a surface and would then prioritize going to this new location to check out the noise, through the On Hear Noise (pawn sensing) Event. However, as mentioned previously, this does not currently work yet. Though, explaining the thought process behind this Blueprint would still be good practice. 

The purpose of this Blueprint, is that when the rock hit an object, the Ai would run the Break Ai Stimulus node, so that it would go off it's random roaming and would begin searching for the noise it heard.  Making sure to also Cast To FirstPersonCharacter so that the Ai could detect the player if they were near the area the area of investigation.

This would then link to the Set Investigate node to true and link to the Ai MoveTo node so the enemy could change it's position and path towards the sound. If when it reached this new location it could not find the player, it would wait a second before ending investigating the area and begin roaming again.

Despite this not working, here is how it looks to demonstrate:

Why this does not work could be for multiple factors, but the reason it is believed to not work is because this new Blueprint inside of the Ai is not properly linked with the base Ai random movement. Meaning, this Event is not actually running as intended. This, or potentially the pawn sensing is not set up properly to actually detect this noise so the Ai could not hear the sound being made.

As this was something the game could benefit from but with no clear method to resolve the issue, it would be a problem to be fixed as a priority in the future above the other bugs.

Unreal project - More features, lights:

Something new that was explored was to potentially allow the player to turn lights on and off across the level. This would be done through a custom designed index that would check that the interacted light switch would be associated to a specific light source within the level. 

The lights did not have to look amazing for the time being as this was more of a test to see if this could be achievable before the deadline. Setting up a Boolean and and integer to both check if the lights were turned on and if the specific lights associated within their allocated index were interacted. 

For the lights Construction Script, all of the spotlight objects needed to be assigned to the Set Visibility node so that when the light switch was interacted, they could turn on. By default, the value of this was set to false so the lights would not start on by default

Within the main Event Graph, the Construction Script Event would be used to check if they were already off, to stay turned off unless they were otherwise turned on by the light switch. This was done through a NOT Boolean as it would then allow the lights to remain off only until a certain value was met.

This new value would then set the new visibility through the Set Visibility node.

Unreal Project - lights continued:

For the light switch, this would require a few extra nodes and features to register the light turning on and off. Additionally, using an array to call the specific light index to the associated light switch so that the switch being interacted would only work for the specific lights. 

Upon Event Begin Play, it would Get All Actors Of Class (for this, it was the light Blueprint that was just designed), and For Each Loop, the actors would be linked to the array and would add them. Meaning that when the game would begin, the associated lights were tied to the light switches array and vlaue.

On top of this, the Begin/End Overlap Events were used so that when the player was inside of the collider, it would allow them to Enable/Disable Input with the light switch. The 'E' keyboard Event was used because the Interaction Event was also tied to this keybind and for testing, this method was used to see if it could still work this way.

If the 'E' key was pressed, this would enable the Enter function of the Gate, whereas Open/Close were tied to if the Enable/Disable Input was running. This then would go through another For Each Loop with the lights array, this would then run everything the loop was doing until it was finished. 

The target for the loop was the Light Index, this is how it could check which index was being used for the switch. If the index for the switch and the light index within the light Blueprint were the same value, it would then sync to a Branch and then run the TOGGLE LIGHTS Blueprint Interface. 

In short, if the light index for the current switch was set to 1 but the lights placed were set to 2, then the switch would not work with those lights.

Although this should work, as intended, there was some unknown bug that was preventing the lights to turn on when the switch associated to the lights index was interacted. The only conclusion is that potentially something in the Blueprint was not linked correctly or that using the 'E' keyboard Event was conflicting with the other Interact Event. 

Nonetheless, this should not be a difficult fix to implement, though this was not necessarily a desired feature such as the distracting mechanic that does not yet function.

Unreal Project - next decisions: