Night Terrors - Puzzle | Horror | VR
Many of us remember what power our imagination held as a child, but we also remember how it worked against us.
The dark: something relatively harmless all things considered, can be the end of a small child, as it houses of all sorts of hideous monsters. How would you feel if you were to step back into the shoes of that frightened child?
Night Terrors is a VR puzzle horror game where you play as a preschooler trying to elude a terrifying monster hiding in the nooks and crannies of your home. To escape, you need to explore your surroundings through the eyes of a child, solving puzzles and overcoming your fear.
My role as game director of the project had me oversee the documentation of and adherence to our design and vision. I was in constant contact with all members of the team, making sure that we all had the same idea of where the project was headed and having to make hard decisions when the team was divided upon an issue. An important part of this was working to ensure that all the choices made were coherent and adding to our experience in a positive way, and not becoming a series decisions leading to a feature-creep leaving the game filled with half-finished mechanics by the project deadline.
I’ve always considered myself good at communication and being part of a team, and this project made me realize just how important it is, even in a small team where you all believe you have the same idea, to communicate why an idea belongs in a project and what it will take from the team to bring that idea to life.
Production time :
Oculus Rift / HTC Vive
Unreal Engine 4
3 x De
6 x 3D-Artists
2 x 2D-Artists
The light and dark – Player movement
The concept of movement in VR is always tricky, especially when it comes to where the players can move, why they can or cannot, and when they can and cannot. We figured that our puzzles should be contained to certain areas of the game, and a way to keep the player within that area would simply be to have the reward of completing a puzzle be expanding their area of movement, as their goal is to get away from their current location. The concept of light and darkness in relation to the character’s movement was therefore contextualized by having the child protagonist of our game be afraid of the dark.
We had to communicate this to the player early on, and did so by having one of our 2D-artists draw something that resembled a child’s drawing on the very first door you encounter to get out of the child’s bedroom. The drawing states that the light is safe, and that the darkness is dangerous.
We also had the reticle of the teleporter change colors depending on where the player was pointing the desired teleport destination for a constant reminder that the child will not move into this area if you try to teleport there. In addition to this, we were going to have the child’s companion, a Teddy bear, deliver a few voice lines about this concept. This feature was however cut from the final version of the game (see Teddy; the darling that was killed).
There was a lot of discussion early on about how we should handle the puzzles in terms of complexity, both from a user and development standpoint. Our original idea for the game was a deviation of the concept of real life “escape rooms”, where the participants are locked in a room with a time limit to figure out how to escape. These are often team exercises that take place over the course of an hour, and seeing as how this is a single player game with an upper time limit of 20 minutes, we quickly ruled out the possibilities of being as complex in the puzzles as these escape rooms tend to be.
We therefore limited the player to be within certain areas of the room at a time, with a focus on the one current puzzle that they need to figure out before proceeding. The puzzles themselves mostly revolve around lighting up the next area of the room so that the child dares to go on towards their parent’s bedroom door, and they are heavily based on observation and interacting with objects that are strewn about the room.
The TV puzzle was the most complex puzzle in the game, and consists of smaller pieces that all had to come together before the player could proceed. The TV is of course the light source that is enabled when the puzzle is fully solved, but it isn’t as easy as walking up to it and pushing the “ON” button. The TV was in a dark corner of the room, leaving it inaccessible to the frightened child, and needs to be activated via a remote. The remote, however, is missing its batteries. Extra batteries can be found in a “Totally-Not-A-Gameboy” handheld game device.
This device is up on a shelf, so the player needs to find a stool to push over and stand on top of. Then, the game device’s batteries are locked behind a plastic hatch on the backside of the device, a screw fastening it in place, so the child needs to look around the area for a screwdriver. Once the screwdriver is located, the puzzle’s solution can be completed very quickly, and let them pass on to the next area.
This whole concept of logic chains was supposed to be cornerstone of every puzzle for the game, but as we quickly realized this could become difficult for the player to understand in the small amount of playtime at their disposal, we stuck to only having one of these more complex puzzles, as they in a sense were five or more puzzles all in one.
Teddy; the darling that was killed
As is well known with all projects, sometime you will have to kill your darlings. This project was no different, and the most centric darling that had to be shelved was in our case “Teddy”: a helping hand for our little child protagonist. Teddy was meant to be there for the player to provide hints if they got stuck on a puzzle for longer than a certain number of minutes, as well as act as a “teleportation device”. As the child is too afraid to move out into the darkness alone, Teddy was meant to be there to support the child and provide them the courage to move into the dimly lit areas of the house.
The mechanic was going to work one of two ways: you either throw the teddy ahead of you, as the child’s logic would determine that Teddy would check if the next area was safe. If the player threw Teddy into a lit-up section, the child would then close their eyes and run towards the spot where Teddy landed, effectively contextualizing a teleportation mechanic in a realistic setting. If the player were to throw it into the shadows,
Teddy would come back to the player and say that the area wasn’t safe to enter, and the player would stay put. The other way he could have worked would be to have the player hold teddy in front of them while holding a trigger on the controller, emitting a small light from Teddy’s chest onto the floor in front to indicate where to teleport, and upon trigger release, the player would either stay put or teleport depending on the same reasoning as the one above.
The reasons this entire concept was scrapped were many. Even though the idea was very interesting as well as added some interactivity for a larger portion of the playtime, the idea of implementing the former type of teleport would in fact add time spent to do such a simple action such as moving. Throwing the teddy could also potentially be horribly inaccurate, and could cause unnecessary frustration when wanting to move shorter distances. The latter option would have been the easier to implement, as this is pretty much how the teleportation works in the game in the final build, minus actually having to carry and point Teddy at the desired location. This function was scrapped because moving a larger object such as a fluffy stuffed Teddy bear around the view-port of the player could be obstructing the player’s view and make it harder to discern where the teleport would move them. In addition to the already mentioned issues, both methods would require the player to always occupy one of their hands with Teddy, which limited the possibilities for interactive puzzles. There definitely were measures that could have been taken to implement these features while addressing multiple of the problems listed above, but given our short production time we had to make a hard choice, which in this case resulted in removing Teddy from the equation and create a teleportation system that functioned without any gimmicks and puzzles that were more intuitively presented to make up for the lack of a hint-system.
Being an amateur voice actor and musician, I took upon the task of designing all audio present in the game. This proved to be a rather difficult task to juggle while also overseeing the entirety of the project’s advancement in addition to writing and practicing to pitch the game to a jury, but I believed I could do it well, and that would be the end of the discussion.
The role of sound designer had me sourcing and editing sound effects for the main character, the environment and the monster. In addition to the sounds, I recorded a soundscape/ambience controlled by a dynamic ambience engine created with UE4’s Blueprint system.
Soundscape & ambience engine
When first setting out to create the soundscape for Night Terrors,
I made a collage of the different ambient sounds that I wanted to use for the game. I was working with Apple’s proprietary digital-audio-workstation Logic Pro X, recording and mixing a lot of different experimental keyboard sounds and recordings of myself doing guttural monster growls, laughs and other foley-work for the creature moving around the house that the player is making their way through.
After the soundscape sketch was exported, presented to and greenlit by the team, I started creating the individual tracks from the sketch into longer, looping pieces of audio.
This was to prepare them to be a part of the dynamic ambience engine that would turn certain tracks on and off depending on where the player was within the game world.
The ambience engine was made using UE4’s blueprint visual scripting, creating game-actors consisting of volumes that send a message to another blueprint containing all audio tracks, telling that actor what track to mute/unmute, or whether it is to mute/unmute all ambience tracks. The system works so that whenever the player enters a certain area of the level, contained by a overlap-trigger volume, the trigger sends a message to the ambience engine.
The ambience engine blueprint then receives the information about which track it should mute or unmute, and does so. The audio in the engine itself is 2D/directionless, but is mastered to change in volume and L/R-panning in the track itself.
The monster sound uses a similar system to the ambience engine, but is made to play the desired audio clips once instead of having them on a constant loop that is just muted or unmuted.
The monster’s sounds vary in intensity, and encompasses movement within the walls of the house, growls, laughs and clicks or hisses. The sounds were recorded with a Blue Yeti USB-microphone and processed in Logic Pro X and Audacity. As the monster were meant to be moving around in the dark, inside walls or quickly across the floor, a lot of the mastering that was done on the audio was limiting certain frequencies of the audio clip, mostly lowering the prominence of the treble frequencies. There was also done some work with shifting the pitch of the recording down a few semitones, adding a slight echo and reverb as well as mastering the previously mentioned panning and volume to simulate the monster’s movement throughout the house.
In addition to the difference in how the playback works, the trigger volumes used are also often smaller, made to be triggered by a movement of the player’s hands towards an object specifically, rather than using a larger area to trigger the effect.