Role:
Programmer
Engine and Tools:
Unreal Engine 4
Blueprints
GitHub Desktop
Team Size:
9
Link Coming Soon!
Balaam Manor is a single player puzzle thriller, set in the titular house of Balaam Manor you are tasked with completing puzzles, uncovering the mysterious story of the manor and those that may still roam its long lost halls.
The game offers a single player experience where players make their way through a haunted manor, making their way from room to room along creaking old floorboards, sometimes the sounds in the house aren’t necessarily your own.
Puzzles that the player encounters will vary depending on rooms. From the classic placing of objects in specific orders to decoding and solving riddles using the environment. Completing each puzzle opens a new part of the house and a continuation for players to investigate the manor and its previous residence, uncovering their faiths and dealings with the biblical forces that may be the cause of your own current predicament.

Continue reading for a short summary for some of my own personal favorite contributions to the project, a bit of the idea behind their design and implementation:
The Piano
A particular personal favorite comes in the form of the secondary main puzzle, dubbed “The Piano”. Simply put the piano is sequencing puzzle where players have to play a section of a short lullaby using the piano provided within the room.
When interacted with, the player is greeted by a piece of sheet music, stained, bloodied, and floating in the air in front of them. The only parts visible are a short section of notes on a music sheet and a set of dots marked with corresponding letters.
The aim of the puzzle is for the player to decipher the sequence of notes using the provided imagery and keys to then play said sequence using their keyboard. Each key press correlates to a note on the piano playing the tune.
Piano Keys
While all other puzzles within the game has the player interact with the world using the mouse, the piano, once interacted with, instead switches that format to have the player primarily use the keyboard. The reasoning for this is quite simple, not only would the keyboard lettering provide a very simply explained rule set for how to interpret the clues to decipher the sheet (having a unique letter correspond to every note) but the somatic component and layout of the keyboard could also be used to emulate the interaction of a real piano.
In this particular case the middle row of keys where used to play the white keys, while the top lettered row of the keyboard was used to play the black keys. The section of letters chose was also spaced in such a way that it would match the keys of the piano as much as possible.
The end result made the experience feel more immersive as if to put the players in a position where they had to play the piano themselves. The somatic input matched up with visual responses on screen with the keys being moved up and down corresponding to the players keyboard input . As well as audible feedback through notes being played and maintained as long as a key was being held down added up to an experience that would make the piano feel more interesting to interact with.
Additionally the piano was in no way locked to the singular instance, once the player had completed the sequence the piano was free to be interacted and played with to the players leisure provided the room was accessible to them.
Feedback
The resulting feedback from tests (as provided by the team members who conducted them) was quite positive with people enjoying not only the puzzle sequence as a whole, but the ability to sit back down at the piano to just play around with it as a musical instrument. One instance in particular reportedly had the tester sit down to play with the piano for some time longer after the puzzles completion, completely ignoring the rest of the test session.
Shifting paintings
Early in the development a choice was made for the general tone and mood of the game being “creepy” or “unsettling”, several systems were discussed to facilitate and enhance these feelings to the player.
Among them a small scale system was developed where paintings could shift their appearance back and forth when players were not looking at them.
The way the system at its core was planned was by having paintings change their image to unsettling versions when not observed. Once observed in their new “creepy” state the paintings would shift back as soon as they were unobserved again. Thus hopefully achieving a sense of contradiction in the players themselves over what it was they actually observed furthering the feeling that something in the game was amiss.
Now you see me, Now you don’t
The shifting effect was achieved very simply by giving the paintings an internal counter, once the counter had reached its end paintings would test to see if they were within the players visibility and if not change to a pre-determined “creepy” image.
Once changed the image would remain “creepy” until observed by the player, at which point it the painting would wait until the player stopped observing the painting, and change back to its “normal” image instead. The counter would reset and the painting would begin its wait for shifting once again.
An early version of the “shifting paintings” system. Testing the observational check to ensure the painting shift and resets correctly to produce the desired effect.
Green represents the “normal” image while Red represents the “creepy” image.
Managing multiple paintings
Later on a manager was produced in collaboration with a teammate to better control multiple instances of paintings within the play space, as per the design if all paintings suddenly decided to shift to a “creepy” state and then back all the time, the player would be able to notice the system much quicker and figure out what it was before it could have its desired effect.
The way this manager was produced was simply to store all the different instances of paintings, containing a singular universal timer, that would then check for unobserved paintings to change. And maintain a count on the current number of paintings up to a maximum. If a painting changed back the system would be notified and given the go ahead to begin its timer again should it have deemed it suitable to switch another painting to maintain a constant stream/illusion.
Feedback
While internally the painting system was considered a success and interesting system, ultimately due to time constraints and focus being put on completing other systems/assets the paintings ended up not getting implemented in the final level.