Monochrome

I believed it was a good idea for the player to have a mannequin as their non-human companion. Similar to what portal does with the heart cube or Firewatch with Forrest Byrnes. The reasoning behind incorporating this into the game is because the game itself has no NPCs. Giving players something they can be attached to, a behavior you would expect for a person in isolation. After all, human beings are social creatures by nature.

To increase players interaction and connection with the inanimate object, players will be able to find clothing items and props around the map, thus boosting exploration. These collectibles can be used to customize their companion. Further into the game the companion will be added to the horror aspect of the game. Disappearing one of the days and reappearing in different rooms or in front of cameras to give the sense that its alive, making emphasis on the characters dissociation with reality.

I think this mechanic is a more organic way to indirectly force players to explore the level. Basically, at certain intervals the character will receive text messages from their partner, and they will need to answer to boost the sanity levels. The reasoning behind this is related to the impact social media has nowadays in everyday life. Being unable to reach loved ones nowadays is a lot more anxiety inducing. This mechanic plays around with the feeling of being left behind and makes emphasis on the distance between the character and their home.

The way the mechanic works is that there will be areas on the map where the player has enough signal to send a message. The player will have to find these areas by paying attention to the signal bar on their phone. The closer the player is to the rooms with signal the more bars will appear. Having three bars will allow the player to send the message and thus boost their sanity levels.

The areas where the signal location will be chosen at random from a selection. These areas will have anomaly triggers that will link to the players narrative.

Finally, a task machine that will print out daily instructions to the player. Once the player is done with the main task, they will need to go back to the task machine to submit their progress and end the day. This machine will provide input to the player via audio queues which are basic robotic noises, replacing normal dialog between them and a supervisor.

I believed that having the machine instead of an actual person giving the tasks will create more distance between the player and human interactions.

As you can see by the engagement loop, players will end the day once they have finished all main tasks. If the player were to interact with the machine without completing the tasks, the machine will emit a failing sound and nothing else will happen.

At first, tasks will be mundane and normal (randomly generated from an array), but later on will become very odd and prone to enduce insanity to the character.

The original plan was to have user testing throughout the entirety of the production section and final release. However due to constant delays and bugs showing up, it had to be left out to the last sprint.

Within that sprint we tested the game in person with groups from other programs/courses. They gave us lots of feedback which helped improve the game and how it presents itself to the user. Unfortunately not all feedback could be addressed and there was still a lot to improve in terms of user experience.

Audio Design

To increase the use of narrative elements, explore main character's personality and response to the events; As well as acting as player's guidance or feedback to action they may want to try or don't know they perform, more than 20 voice lines where written down and iterated through. However only 16 of them were actually introduced into the game due to time restrains.

Dialogue lines that I recorded myself where mostly related to picking the wrong item, or interacting with an object without having the correct tools, etc. Good example of these dialogues are:

"Why would someone leave this here?" (Finding a tool)
"Hello? Someone there?" (Low sanity)
"Of course... No signal" (Sending text without signal)

What you see above is an early development video of the inverse kinematics working within Unity Engine to make the player walk up stairs.

After watching a few videos in the subject and Unity's Documentation, I was able to generate somewhat of a working and believable walk that will bend the player's knee and position the foot's angle and position based on the distance they had to the floor. Thus, instead of hovering over objects they will realistically stand on them. I can recommend the following video which I used as a guide: Inverse Kinematics Video.

However, lack of experience utilizing Inverse kinematics pushed me to find a different soulution to allow the character to distinguish objects on different heights using raycasting.

The way I utilized Post Processing during development had a drastic change half way into the project. Originally it consisted in having two cameras stacked on top of each other.

One would render UI elements and objects I would like to highlight and keep unchanged by the grayscale or other effect, while the rest would be influenced by them. When HDRP was introduced, I was quickly introduced to a new problem.

This meant that camera stacking was no longer possible and the tools used to create volumes was different and more complex (mostly had more options and settings).

Post-Processing was changed once more when, suggested by the lecturers, that the effects would start to show up as the sanity decreases. Thus, making the sanity system clearer to the player and not loosing the detail on the assets made by other team members in the process.

Rapidly having an event system via delegate to manage Sanity levels, while those who require values form it to act as listeners, thus avoiding overflowing the Update method and improve frames, allowed me to spend more time on the Anomaly system.

I first created a handler, which would have a reference to each anomaly in the scene and would trigger one at random within a designated amount of time which could vary depending on the current in-game day or difficulty.

I also created certain checks to prevent the same anomaly triggering multiple times and an enumerator to distinguish between different anomaly types.

Use of Polymorphism

The Anomaly class is an abstract class that inherits from the Interactable class. This allows me to create multiple different version that override the main class's functions. The main reason why I used an abstract class was to be able to trigger anomalies directly by just having the reference to the abstract class instead of having different lines of codes to do the same thing over and over to different classes.

Within this class, I state a few different things that are essential for all anomaly types. This being a Trigger, Fix, isActive (to check whether it has been triggered before or not) and references to its original and current state to be able to fix them later or keep them persistent through scene changes.

I started by gathering animations from Mixamo, which facilitated the rigging process since it does the rigging for you. Some manual adjustments were needed inside the editor but the whole importing was pretty fast and quite efficient.

Setting up the animator to properly flow between one state to another proved to be a bit more challenging than what I thought. At first I decided to implement a Blend Tree which would allow me to quickly and naturally transition from one animation to another. The way I decided to implement it, was by mapping the player's input number (basically if he is moving forward or backwards -1 to 1 or left to right -1 to 1). This number was generated by the engine depending on the player's hold of the corresponding key.

For running and interacting I just had a check whether the player is holding the respective or not, and for idle animations I had a timer that would trigger if the player wasn't tiggering any command. In addition I also added different variations to give a bit more life to the character, which would also vary depending on their current sanity. After a lot of iterations and remakes, the flow chart ended up looking like the one below.

The idea behind the character was to keep the polygon look that old games used to have but with a slightly increase of quality of visuals.

I started by placing anatomically references of our main character's shape. Then continued by modifying a cube to look like the torso. I managed to do this by moving the vertices to the correct positions and then adding more lines as the modelled required more detail. Then I extrude parts of the torso to transform them into extremities. This new meshes would then be mirrored using Blender's Mirror modifier which really sped up the process. Once this was finished, I followed with making the mesh smoother.

However it would later be pointed out to me, by our Digital Sculpting teacher that I have overlooked some key elements to make a good model. Looking at all the work needed to be done, plus the time restrains, I decided to go for a much simpler option; Creating a character model using Fuse (a 3D modeling app for quick export of working character models).

Thanks to Unity's intuitive UI and some documentation reading I was able to quickly map the bones and muscles to the character, with the help of previously utilizing Mixamo's rigging capabilities.

However, importing the character and applying the textures always seemed to have scaling problems, as well as shadding. To make things worse, the movement system implemented caused animations to be snappy, or overall broken. I spent a lot of hours trying to fix such problems, but every new change in the code base brought up a lot more problems. Leading to other parts of the system being broken down such as the idle animations and the smooth transitioning between them. From unexpected leg wiggles to complete deformations on the rigs, the system never truly work as expected. To add to the mentioned problems, there was not enough video tutorials or documentation that would help me find a solution within the time I had to work on it.

Other tasks, were starting to pile up and I needed to find a solution; fast. Thus I simplified the system and lowered the amount of animations to a minimum.