Madhouse: Fall 2017

Itch.Io Link


Madhouse is a first person thriller that has the player experience a story from three different perspectives. They player begins inside Lockwood Manor Mental Facility as an investigator in 1951, then experiences flashbacks to 1941 as both a new nurse and as a delusional patient. Solving puzzles along the way, the player also is able to find extra clues hidden throughout the manor that provide extra context for the game’s main characters.

As a programmer and tech artist on this project, I was tasked with a bulk of the game’s progression systems and interaction mechanics. These included line trace interactions with objects, level stream work, puzzle systems, as well as video and cutscene implementation. I also worked with UI controls and implemented a graphics option menu so that the game could be played smoothly on machines with graphics cards in the GTX 600 series.

Key Programming Tasks Completed:

Doors / Switches / Buttons

To start the project, some basic tasks were assigned to get the team more comfortable with Unreal Engine 4. I began first on making some basic interaction code that applied to the doors, switches, and buttons in the game. A trigger was used near the objects, upon entering the trigger, a line trace was sent from the camera forward to detect if the proper mesh was hit or not. After this, there was some slight variance in the needs of these blueprints.

Doors needed to open in both directions, close from either, and lock. If locked, the door was to jiggle a bit. Because of the trigger method used above, I decided to create a second trigger, and place one on either side of the door. While in one trigger but not the other, the door will open away from the player. If in both, the first one entered will dictate which direction the door opens.

Button_GIF.gifButtons were to recess into the wall, then slowly return to their original position. Doors could also be assigned an int value by designers, and buttons pressed in order, from 0 to a number assigned on a corresponding door, would unlock that door. If a button is pressed out of order, all buttons are reset.

The switches were simple as well, and were meant to be flicked up and down at will. At various points in our game, unique events were called, and things like level lights were controlled with the switches.

Overall, I was happy with how bug free all of these blueprints turned out.

Level Streaming

The game takes place in three different versions of the asylum, as well as two other unique locations. Each location had a separate level stream for architecture, dynamic assets, static assets, and lighting. It was my job to make the streaming process as smooth as possible, so that the player does not notice the loading much, if at all.

This was done by calling the proper functions in a sequence, directly after beginning an .mp4 cutscene for the player to watch in the meantime. With much trial and error, I learned which order to call events in to avoid visual hitches (black flashes and such). The result came out looking clean.

Maze Puzzle

The maze was built using three way intersections, with two halls at each intersection containing a smoke wall. If the wrong wall is entered, the player must start the maze over. In order to complete the maze, the player must enter the correct smoke wall at every intersection.


Light Puzzle

The light puzzle followed a similar design. Upon gaining control, the player is in a new area. The space is void, but there is seemingly endless knee deep water. Ahead, one spotlight shines down, and upon entering it, two more appear ahead. Black starts to fade in around the player’s screen. Upon entering the wrong light, more damage is taken, and the player grunts. Upon entering the correct light, the black is pushed back to the edge of the screen, and two more lights appear. After successfully entering four lights, the puzzle is complete, and the player advances.


Story Progression

Through use of static variables stored in the game instance, in this case a couple of ints, the state of the game was kept track of. The key things tracked were the number of flashbacks completed, and which character was being controlled. One blueprint was created with a trigger to control this, the Flashback Trigger Blueprint. These were placed at several key locations throughout the game, and triggered the .mp4s to play, and also had level stream functions inside.


The above picture is an example of one macro, a switch case for the ending of the flashbacks. On the left of the image are the other events, functions, and macros used in the Flashback_Trigger_BP Blueprint.




Comments are closed.