Ratcliff Estate

A stealth strategy game in which you rob a graveyard while a monstrous creature that protects the grounds stalks you.

Platform

Role

Year

Team Size

Engine

Windows

Systems Designer

Spring 2024

Unreal Engine 5

My Role

I was one of two system designers on the team. While the team collectively came up with the general game idea, it was my job as a designer to iron out the details of game play.

I made our concept document which outlined what our game would be. The intent of the gameplay experience is to put the player on edge as they balance between stealthing around the creature and desperately running away from it.

I had a large part in programming and implementing these systems. I implemented the graves which meant programming the treasure and hiding systems. I collaborated with one of our programmers to create and iterate on the monster AI. I also helped with smaller details like camera work and lighting.

The Concept Document I created at the beginning of this project.

The player digging up a grave.

The player getting spotted by the monster and running away.

The player hiding in a coffin.

The player utilizing the camera movement to look all around them.

Challenges

Providing the Player with Information

The moment we started developing the game a major question came up, what information are we giving the player? In a stealth game the player needs adequate information to be able to make choices about how they move around the level. I took on the task of making design choices to improve both the visibility of the level and the readability of the monster.

Visibility: Camera

The camera angle was very important because the player needed to be able to see the monster from far enough away as well as have a way to survey the surrounding area to make a plan.

The initial idea behind the high camera angle was so that the player could see the level layout better.

However the problem was the player couldn't see the monster unless it was immediately nearby.

This was the very first iteration. The player standing in front of a grave digging it up and the monster just came running into view.

The close camera angle was made to test how it felt for the player to constantly be keeping their head on a swivel.

While this put the player on edge, it took away the purpose of stealth. The player couldn't sneak around the monster since they simply never knew where it was.

This was a second iteration. The player standing in front of a grave, there is dense fog around them.

The happy medium ended up being an angle that allowed the player to just barely peak over the walls. The player was also given more control over the movement of the camera so they would be able to see from all around them as well as adjust the angle slightly.

This is the final iteration. The player is moving the camera to look all around them.

Visibility: Lighting

The lighting was just as important as the camera. The artist wanted fog in the game to create a spooky atmosphere but the initial fog was so thick you couldn't see anything. This fog completely cut off vision at a certain point made it too difficult to navigate the level or spot the monster.

This earlier version of the fog completely cuts off the players vision after some distance.

The final decision was to make the fog lighter and provide other sources of light that could cut through the fog like candles to not have the player totally lose their bearings. While lighting would normally be an artists job I worked on it because visibility was so important to our game. This shows how important it is to consider the game as a whole and all the aspects that make it work, not just the base mechanics.

This was the final iteration. The player is running through the level, while the fog obstructs their view the lights can still be seen from a distance.

Visibility: Monster Readabilty

The first version of the monster was difficult for the players to keep track of. It was hard for players to avoid getting caught because they wouldn't realize the monster was nearby until it was too late.

To fix this problem I added cones of light to the monsters eyes. This not only let the player track the monster from further away but also allowed them to know where it's field of vision is.

The monster is seen here with it's eye lights. This is the color when it is patrolling.

While players now knew where the monster was, they were struggling to know what it's current behavior was. There wasn't a way for them to visually tell when the monster had stopped hunting them. This was fixed by changing the color of the light in the monsters eyes depending on it's behavior. Now the players would know if the monster was headed towards them because it heard them, or if the monster was merely roaming.

Orange lights means the monster is investigating a noise.

When the player sees this color they know they should quietly get out of the area.

The monster eye lights are orange, it heard a noise but hasn't seen the player.

Red lights means the player has been spotted and the monster is actively chasing the player.

This is the players cue to full on sprint away!

The monster eye lights are red, it has seen the player and is chasing them.

All of this helped to cement the lesson that design isn't just how the player interacts with mechanics or how systems interact with each other. A good designer will also be thinking about what information is being given to the player and how the player uses that information to make decisions in the game.

Designing Monster AI

Designing the AI behavior was the most difficult part. The monster needed to be challenging without feeling unfair. The behaviors also couldn't be too complex due to our limited experience and short timeframe.

The outline for the AI behavior was kept very simple. Rather than adjusting the behavior itself, the two major components that became important in adjusting the monster feel were speed and movement.

This flow chart gives a high level overview of the monster behavior tree.

Defining the monsters speed was important for having it feel fair to avoid. When unalerted the monster speed is slightly slower than the players walk speed. When investigating a sound the monster is the same speed as the players walk. When chasing, the monster is only slightly slower than the players run. The reason why the monster is at first slightly slower than the player is because the player gets slower the more treasure they pick up.

The monster patrol started out as it picking any point in the level to move to. This worked when the level was small but when the level got bigger the player could wander around the level and almost never run into the monster. I fixed this by making the monster pick a point within a wide radius of the player. The monster movement still feels sufficiently random but the player now had more encounters with the monster.