Ratcliff Estate
A 3rd-person horror game where you are robbing a graveyard, and have to collect as much treasure as you can and escape without a monster catching you.
Made for PC using UE5
Cooper Thronson, Carson Griffin, Bea Godeau, Renee Bamford, Angus Goucher, James McKibbin, Ethan Vawter, Jasmine Leong, Nate Spielman, Danni Vecchione
4/16/2024
Systems Designer
Game Balancing
QA Manager
Ratcliff Estate was designed to be a high-score focused game with horror aspects to it, having short play sessions where players must weigh the risk of staying within the graveyard and being caught, and the reward of a higher score for being greedier.
The gameplay of Ratcliff Estate consists of the player running around in a 3D graveyard, with coffins and tombstones littered about. The player is tasked with digging up as many of these graves as possible, gaining money each time they do. The main antagonist of the game is an unnamed monster within the graveyard, who will chase the player when they see them. The monster can hear the players actions, being able to hear louder actions from further away. If the player is caught by the monster, they lose. The player may escape through the main entrance of the graveyard at any time, securing their high score of however much treasure they collected.
The player digging up a grave, with the monster approaching.
I worked as both the QA manager and main difficulty balancer on this project, along with some systems design throughout. I brought this game to our on campus testing labs weekly, retrieving and compiling feedback from testers on topics we wanted to improve and iterate upon throughout the project. Balancing came along with this role, as there was a lot of fine tuning of difficulty regarding the monster, that we got feedback on every week from testers.
The player hiding in a coffin from the monster
When balancing the game, there were a lot of things that I had to consider to improve the overall player experience. the initial thought was just the monster’s speed, which got cut down a ton from what it originally was. However as that got slower and slower, I decided that slowing down the monster is not going to accomplish the effect that we wanted, so I pivoted to tweaking some other things. Some examples of what I changed were radius the monster could hear you from, as many testers felt like the monster always knew where you were. this worked decently well, but players still made noise while running away, and most players were not familiar enough with the map to actually lose the monster. This led to a more robust hiding system, as we had empty graves the player could hide in. This came with its own slew of issues programming wise that we had to tweak where the monster would still kill players within the safe spots, so we changed the open graves to coffins that would effectively despawn the player.
The monster chasing the player, about to catch them
However after making these coffins, they were a bit too powerful for the player to always just hop in one and be fine, so I made yet another change to them. We made it so that if the monster saw you enter the coffin, it would still “know” where you are, and still kill you within. this led to the players having to plan more carefully, actually breaking line of sight with the monster before hiding from it.
One final thing that I had to consider while testing was the clarity of whether the monster knew where the player was or not. When the monster lost a player, we had it so that it went into a “search” phase, where it would look around the area for the player where it last saw or heard them. This initially seemed good, but we found through testing that this ultimately just dragged out gameplay as there was nothing for the player to do while it was searching near them, as it was typically right next to the coffin they were in. We then cut down the time of this search phase substantially so players’ flow state would not be interrupted as much, and it was successful in making a more enjoyable experience for the player.
The player grabbing loot
Our team worked together well to put together this game, although there had been some conflicting views and issues with work scope throughout the project that led us to some roadblocks. However, through regularly meeting and communicating, we tried our best to make the best product we could, with the limited time and resources we had available to us.
This game came out a lot different from the initial vision that our team had for it, through a lot of things in testing that we never would have considered through testing. While we were not super happy with the finished product, this project provided me with a ton of important lessons in the QA field, teaching me to accept change for a mechanic I was attached to much more easily, and how to get around design problems that aren’t as simple to solve as they may seem at face value, tackling different ways to remedy a player issue.