House of Vampires
Roles and Responsibilities:
Utilized C++ scripting and blueprints to develop and iterate on core mechanics including grabbable objects, weighted scales, and limb cutting/reattachment in Unreal Engine 5.
Developed and refined critical game design documentation, including experiential goals, game design pillars, and the implementation of key puzzle systems.
Worked with discipline-specific designers to maintain a consistently frightening player experience across varying modes of play.
Created and implemented custom IK player hand animations using animation blueprints and montages.
Worked closely with the technical art team to integrate bespoke character animations and visual effects with gameplay triggers.
Game Overview:
Escape with only what you can carry… Inspired by classic works of gothic literature and survival horror, House of Vampires is a thrilling puzzle horror experience that tasks players with escaping Dracula’s castle. Think on your feet, use macabre items, and don’t be afraid to make sacrifices as you explore the House of Vampires. This project is a roughly 20 minute long prototype created in 4 weeks as part of the University of Utah Master’s in Entertainment Arts & Engineering program.
Grabbable Items:
As a gameplay programmer and designer, I was responsible for assisting in the creation and testing of the game’s core mechanics. All of the interactions in House of Vampires revolve around carrying, juggling, and using items of various weights to solve puzzles, so we felt it wise to spend the time creating a strong architecture for grabbable objects. We ultimately chose to write the base grabbable class in C++, with child classes being written in UE5’s visual blueprints for designer readability.
As this system was introduced late in the project lifespan, I chose to quickly prototype the animation montage triggers and controller inputs in the base player blueprint, visible below. This blueprint handles the different arm-related actions that the player can take at any time, using an enumerator to determine whether an action can be taken.
The .cpp file for base grabbable objects can be viewed below. This script interacts with the player character script and both player arm scripts, handling behavior for obects to be picked up, dropped, and thrown.
Pressure Plates:
A major focus of this prototype was learning to effectively develop gameplay mechanics within a gym setting, and this process was emphasized by the work I did on pressure plates. Our excellent designers, burdened with level creation and puzzle design, did not have the time to create highly detailed descriptions for their desired mechanics. I was asked to simply create a pressure plate object that, when weighed sufficiently, would open a corresponding door. While this gave me alot of flexibility in designing the plates, I was always careful to ensure that the finished system would serve the designers primarily. I set up the pressure plate blueprints to be easily implemented in-level, simply requring a minimum trigger weight and one or more associated doors to be selected using the eyedropper tool.
Wrapping Up:
This was an immensely rewarding prototype to develop, and I feel quite lucky to have had the chance to work with such a skilled, patient team. I’ve listed a few notes about the development process below.
My biggest goal for this project was to improve the readability and documentation of my code, and I think this was a success! In both C++ and blueprints, I made sure to clean, comment, and document every mechanic that I tested and feature that I implemented. This resulted in smoother communication and faster collaboration with the rest of the team.
This was my first time writing C++ code for a game, and I learned many valuable tips about organizing header files, utilizing pointers, and building UE5 projects from the IDE.
If I have one takeaway from this project, it’s the importance of regular playtesting from all members of the team! My fellow engineers and I spent so much time developing mechanics in the gym that we forgot to test the designer’s levels to see how our work was being implemented. This resulted in some avoidable miscommunication, with requests for altered features that I would have been able to anticipate were I playing through the designer’s puzzles. Moving forward, I plan to regularly playtest throughout all stages of development so that I can stay in tune with the game’s vision.
House of Vampires can be played here. Thanks for checking it out!
Limb cutting was a fun challenge to implement, as it interacted with many different systems in the game and required that I closely worked with multiple team members. The logic for losing the actual limb was implemented using c++, and can be seen below.
As the team member who proposed the limb cutting mechanic, it was my responsibility to handle any additional work that this system engendered - but I still roped in some colleagues for assistance! I created a simple blueprint to spawn blood decals (created by a wonderful tech artist on our team!) whenever the arm collides with an object, and created a custom animation using another tech artist’s hand rig for the cleaver chopping action. I also encountered an issue where the player hand model was too large to sit comfortably within the default player gripping animation. To solve this, I set up a branch filter in the hand animation blueprint, allowing it to transition from a narrow to wide grip based on a boolean in the held object.
Platform: PC
Engine: Unreal Engine 5
Production Time: 4 weeks
Size of Team: 12
Roles: Engineer, Gameplay Designer
Link To Game: House of Vampires on itch.io
Weightable Scale:
After completing work on the pressure plates, it was time to develop a working scale. This mechanic was a great opportunity to practice iterative development and interdicsiplinary communication, as the scale went through several rounds of feedback with designers and players before reaching its final form.
One issue we noted during playtests was that players struggled to get objects to “stick” on a pressure plate basket, especially when the object was thrown. To solve this issue, I added a function to the base grabbable object script that enables heavy linear damping on an object’s physics when it collides with something in the scene. The result is that an object can be thrown or dropped, following standard physics rules, but bounces and skitters far less upon hitting a surface. This was not only successful in context of the scale but the entire game, as nearly every puzzle became more reliable during playtests!
Another problem we discovered with the scale was related to animation. The object uses an animation blueprint to shift between weighted and neutral states, but the doors are simply triggered as soon as a basket has the required weight. This resulted in unclear puzzles, as a door would swing open multiple seconds before the scale shifted to its associated side. I solved this by tying the door trigger logic to an animation notification on the scale’s animation blueprint. This meant that placing a weighted object in a bucket would no longer open a door, instead triggering an animation that, on finishing, would open a door. The result was both more realistic and intuitive during playtests.
The below blueprints showcase both the main logic and some helper functions for the scale.
Limb Cutting:
The final major mechanic I developed for this prototype was the ability for the player to cut off their own arms using a cleaver item. Doing so reduces the player weight, deals significant damage, and creates a new grabbable object that can be used during puzzles. By “using” the hand, players can then reattach it, allowing them to again hold two-handed objects. I suggested this idea to the designers after a challenging series of playtests, where we noticed players often losing items or getting soft locked in rooms without enough weighted objects to complete the puzzle at hand. The idea behind this solution was that players would always have a backup solution for handling weighted plates and scales, but only by sacrificing abilities and risking death.
I chose to create the pressure plates using blueprints instead of C++ so that their logic could be read and edited more easily by other members of the team and created a demo room in our gym where the designers could freely test the plate’s function. On a previous project, a team member very politely informed me that my code tended to look like spaghetti, and that my poor documentation made it difficult to work with. I strove to fix that mistake for this prototype, with clean, commented blueprint code and clearly documented instructions for setting up pressure plates in the level. The main logic for the plate blueprint can be viewed below.
