Sinister Studios Games
Game Machanics
As the technical lead, I have to make sure that we know which game mechanics and puzzles to include within our project, so I did some research on a variety of games to gather ideas on how our game should work. I have also done a bit of research on programming techniques that we are going to use as well as how to implement VR through Unity.
The first thing we needed to consider was the perspective this game would be played in; since we plan to implement VR, it would make a lot of sense to develop the game in first-person and make the only commands being movement and action (so it is suitable for VR controllers). This will also benefit our project perfectly as we can fully immerse the player to the horror aspects of our game and make it provide a more personal and terrifying experience, a good case for this is Resident Evil 7, which made a successful conversion to VR due to it enhancing the scare factor for the player.
As with most games, the movement will be implemented so the player can properly traverse the game's environment, along with that, our action button will have multiple functions such as collecting and using items, opening doors, reading documents and others that may be developed later on in production. This will help us develop a variety of puzzles for our game while keeping the controls simple for the player.
Amnesia: the Dark Descent is another game that plays in a similar manner to how ours will play, due to its basic movement mechanics and the action command that allows the player to examine objects, and even interact with doors and carry objects if the player holds down the action command. While it does have sprint and jump mechanics, for our game, the player will sprint by default and there will be no need to jump as we don't have platforming elements planned, which is fine for us as we will still need to keep the controls simple for VR.​
Outside of gameplay, we will also be implementing an inventory system so the player knows what items he/she is currently holding and figure out a way to use them in order to progress through each area. There are many types of inventories that can be developed as different games have different needs; in Resident Evil 4, one can press a button at any time to bring up the inventory during gameplay (which pauses while the inventory is up), and go to a separate section that lists all the keys and treasures the player currently has, the former of which disappears after being used. While this can be useful, it requires an additional button to be mapped, which would limit the amount of VR headsets we can use for our game.
As stated before, there are many ways to develop an inventory system, so one way of resolving the aforementioned limitation is to have key items constantly showing on the HUD, eliminating the need to manually open up an inventory and allowing us to stick with our VR plans. This comes with another problem as including a consistent HUD can negatively affect the immersive experience for the player, so the best approach for us is to include an inventory section, but have a trigger where the inventory will appear only for a brief period once the player picks up an item. This way, the player will still know what items he/she has without the HUD being too intrusive, speaking of which, we may place the inventory at the top of the screen, so the player can easily see the ground for any useful items.
For the puzzles, we are focussing on three aspects; reading notes for clues and backstory, picking up items (such as keys, notes and batteries) and interacting with keypads for locked doors. With enough research, we found that these three puzzle elements are very commonly used in room escape games and they come in many variations to keep the puzzles fresh and challenging for the player to overcome.
Doors & Rooms is a good example of a room escape game that focusses heavily on puzzles; in each level, you are tasked with escaping a 2D room to look around for clues and items, then figure out a way to escape. Throughout the game, there will be notes containing a code which you can type into a keypad; typing it correctly will trigger the exit door to unlock. The game will also allow the player to perform other actions such as using a pair of pliers to cut through a ventilation system (gaining access to a key in the process). Mechanically, a game like this wouldn't work for us as the actions will require the player to tap certain parts of the screen, however, it does provide some good examples on the types of puzzles we can include in a very basic game.
Out of all the room escape game that have these elements, some will only give the player a certain amount of time to escape before being sent back to the main menu (and consequently, having to start the game from scratch). Whether it is a timer appearing on the HUD, or something very frightening, the pressure will be on the player to escape before time runs out (possibly, invoking negative emotions such as panic).
We wanted to include something like this in our game to increase the scare factor, which will come in the form of a shutter mechanic; while the player figures out an escape, the shutters will gradually be lifted by the monster (named Specimen) featured in our game, and after the shutters have been fully lifted the Specimen will start pursuing the player, in which case the latter will die if caught by the former. We decided to do it this way instead of including a timer, as making a scary creature you know nothing about chase after you while trapped in a dark room can increase the scare factor exponentially.
A flash game called Geist - Escape the Death Game did something similar to this; after switching off the lamp, the player is encouraged to click a variety of objects in the room and find the hidden key so he/she can escape before being caught by the 'window man' (which results in a game over screen).
When it comes to programming in Unity, we will be using C# instead of JavaScript; the latter is only used for browser games that aren’t very demanding as a large script heavy game would be very hard to manage and debug, whereas the former is more structured and easier to use in the context of Unity games as all components are well explained and available off the shelf.
For the start, we already have the movement mechanics covered as we will be using the first person character from the Unity Standard Assets, the former of which already has a built-in character controller so we won't need to worry about creating a huge script from scratch. Since we will be disabling the jump mechanic and adding a few triggers that will activate after the action button is pressed, we will need to adapt our character controller accordingly.
​
​As per the Unity Documentation site, enabling VR support in the player settings will result in two things; the cameras will render the scene to the head-mounted display by default, and head tracking will also be enabled (allowing the cameras to follow the head movements). From there onwards, we would have to map our controls according to the input device; for example, if we are using Oculus Rift, one trigger will be used for walking, while the other will be used for the action command, whereas with Google VR, one button will be used for both; press for action and hold for walk.
Due to the simplicity of our game, it won't be script heavy like some of the other large scale games. In fact, the vast majority of our game will be programmed using triggers and colliders; if a collider enters a trigger, the ‘OnTriggerEnter’ function is called and the lines of code indented below the ‘if statement’ will activate (causing an event to happen during gameplay). For our game, there are several ways this can be put into practice; if the reticle enters a keypad button collision box, the game will allow the player to interact with it by pressing the action button (causing another event where the selected number will be typed into the keypad). Additionally, if the Specimen collides with the first person character, the latter will be destroyed and the ‘game over’ scene will be loaded by the scene manager.
