Jay Hriscu Technical Journal - Monochrome

For the projects version control Git Hub is used. It allows for the team to work without any trouble on the project and contribute to it without issues. Merge conflicts are the biggest issues in projects and here as a control as a team we talk to each other in advance before working to agree on what branches are created from where and how we are going to merge it later. This allows us to have as less conflicts as possible.

The game is played in third person. So this means we have multiple possibilities to move the player around. Since the game is inspired by older games such as Resident Evil 1, we decided to go with Tank Controls. We are using keyboard for our movements and as such use the standard WASD keys to move around. With Tank Controls this means W & S are to move forwards and backwards, A & D are used to rotate the character.

Issues after user testing:

After some testing we found out that some people had issues with the controls. With the camera system that we had the players were sometimes confused on how to move the character around.

First version:

The first version of the camera system consists of a single collision box which has a reference to the two cameras. This Camera system was dynamic so it could change to any camera with the trigger boxes. Which includes changing to a third person camera and a first person camera to look at the phone.

Final version:

Camera fixing was the first task I did this sprint. I thought of a lot of ways of fixing the bug that I had of the camera not switching when moving to the next are and came up with a simple solution. That is using two trigger boxes instead of one that are minimum distanced at least so far that the player collision doesn't hit both of the at the same time. It was very hard to accept this solution as I was trying to think for something as optimal as possible but I had accepted that a simple solution that works is still a good solution. In the following picture you can see in yellow the two trigger boxes used to trigger the cameras.

Camera system in action:

Unity uses scriptable objects which are a unique data container to save vast amount of data. We used scriptable objects in our game to represent our items and anomalies. Since we have so many repeating object types a data container that has the same structure for everything was perfect for our systems.

Scene Persistence Issues:

The biggest bug was that the data would reset in each scene. What I found out was that scriptable objects aren't scene persistent. Once the game compiled the asset is saved with the data set before hand. So to solve this issue we pass the necessary objects in a list which is referenced in a script that is a singleton. Which means the script stays persistent with the referenced objects making it possible to pass data between scenes without an issue. 

Loading Level

The game has a loading screen which loads the level asynchronously. The way it works is that while the next scene loads it load a scene that only has a picture on it that's a loading bar which doesn't require a lot to load. And the other scene is completely loading in the background so that the player doesn't see the game loading in real time which might seem buggy.

Day System

When a scene is loaded the Day System checks what day it is and gets the list of items of the current day and the one of the previous day (if there is one). Then the level manager has a OnSceneLoadedMethod which first goes through the previous day items first if they are present in the current scene then they will be setup correctly depending on if the item was interacted with on the previous day (this is important for the optional tasks as they can trigger a cascade). Then the items that need to be interacted with will be put in the current tasks state. After the items receive their state the items themselves will set themselves up on how they should look.

With this system we ensure that all the items are in they proper state and are shown as that as well when entering a scene. 

Diagram of the Day System

The task machine hands the player a reference of a scriptable object for the current day which holds all the tasks he needs to do that day. This works in conjunction with the Day System

Inventory system allows the player to see his inventory in the same style as Silent Hill 1. The player can click on the right or left of the inventory to sickle through all the items he has. The items are represented as these coloured cubes. The way it works is that the inventory has a reference to a scriptable object that has the scriptable objects of the items in them, which then loads up the mesh and applies the material to them which are shown to cameras that are hidden from the players that look at the models and then load them up to a texture file which is then applied on the UI.

For visibility and clarity the inventory was visually changed to fit a more realistic mobile picture gallery application. Which turned out to be more visible for the user. The downside is since we are nod loading 3D models of the objects we need to manually take screenshots of the objects that can be grabbed to make an icon out of it for the inventory to load up.

Mannequin Inventory system allows the player to use the picked up clothing items to equip them on the mannequin. In the following gif you can see that a "Hat" is being equipped and unequipped on the mannequin.

An outline shader had to be made to highlight the objects when the player is near them. Using Shader Graph in HDRP I created a Unlit Shader Graph that simply takes the objects position and multiplies it with an outline thickness which is 0.01. The setting of the cull is set to back so that only the polygons from the inside of the objects are seen. This created an outline effect that works on every mesh.

Shader in action:

A simple door system that opens depending on which side the player is and open up to 90 degrees.

The phone signal works in such a way that it uses collision boxes that when entered tell the player what signal strength he has. At 3 signal strength the character can write a message to regain his sanity to his wife.

This was the first prototype level for the game. It has a small legend indicating what means and is build in such a way that it focuses on the main theatre hall being centred and everything around it is build to traverse and access it. The intention was that the cinema room was the focus point of the map and everything around it somehow connects/leads to it.

After the paper prototype presentation we got feedback from the teachers in all aspects of the game. As a level designer and programmer I reflected on these aspect for the game.

Player Movement: Ease of use

 It felt too confusing to move around the game so an alternative control scheme has to be used which most like will be a standard third person controller. 

Static Cameras: Visibility

 In terms of the cameras there where problems with visibility and distance which can only be fixed in the design placement of the cameras. The player should never feel like he has to approach his screen to see if there is something.

Level Design: Liminal Spaces

Liminal spaces was a term that was brought up which fitted our game and after some thinking I realised that the design of the theatre should have a familiar feeling. Meaning that walking around the theatre should feel like walking around a real theatre but in a state which no one really experiences which is walking through a empty theatre with no one around. This could be used as a great advantage for atmosphere in our game.