MIRRORED PHANTOMS

View on Steam

Mirrored Phantoms is a first-person psychological horror game set in an abandoned mannequin factory where reality distorts around you. Players collect shattered mirror shards, solve eerie puzzles, and navigate shifting environments while evading lurking phantoms. With atmospheric tension, unsettling visuals, and a slow-burning mystery, the game challenges both perception and sanity.

Development Specifications:

Role: Graphics/Gameplay Programmer
Team: 21 developers
Development time: 5 Months
Engine: Unreal 5.4

MY RESPONSIBILITIES

Integrated DLSS support to enhance performance and framerate
Utilized Nanite to significantly improve visual fidelity
Implemented a true mirror using real-time reflections
Developed a Save and Load Checkpoint System for seamless player progression
Implemented a Level Streaming System to optimize memory usage and loading times
Designed and implemented interactive gameplay mechanics, allowing players to engage with the world in creative ways
Collaborated with programmers, artists, and designers to optimize gameplay systems, visual aesthetics, and lighting for a polished experience

DLSS Support

I integrated DLSS (Deep Learning Super Sampling) support into our project using Unreal Engine’s DLSS plugin, ensuring improved performance and visual fidelity. This involved enabling the NVIDIA DLSS Plugin in Unreal Engine and configuring it within the Rendering settings.

I also exposed settings in the project’s UI, allowing players to dynamically use DLSS based on their hardware capabilities.

Nanite Support

I implemented Nanite support for our team project to enhance visual fidelity. Nanite, Unreal Engine’s virtualized geometry system, allows for highly detailed assets with automatic LOD management. By integrating it, I enabled the engine to handle massive amounts of geometric detail efficiently, reducing draw calls and memory overhead.

This improved performance, especially in complex scenes, by ensuring only the necessary level of detail was rendered at any given time. As a result, we maintained high visual fidelity while optimizing rendering performance, making the project more scalable and efficient.

Given below are scenes of the game level in LIT mode and NANITE CLUSTER mode to showcase which assets on screen are using nanite and to give an idea of what percent of the total assets use nanite.

Scene 1

Scene 2

Scene 3

Mirror implementation

In my implementation of a real-time mirror in Unreal Engine, I opted to use a Scene Capture Cube Component instead of a traditional 2D Scene Capture Component. This choice was driven by the need for accurate reflections from multiple angles, ensuring a more immersive and visually correct representation of the environment. The captured scene was rendered to a Render Target Texture, which was then applied to the mirror surface as a material.

Performance Considerations and Optimizations

Rendering the entire scene a second time for reflections is inherently expensive, so I implemented several optimizations to mitigate performance costs:

Frustum Culling for the Mirror Object
- To avoid unnecessary rendering, I implemented a frustum culling check for the mirror blueprint object. By leveraging Unreal's visibility checks and custom logic, I ensured that the reflection rendering pipeline was only executed when the mirror was within the camera's frustum. This significantly reduced the overhead, as reflections were not processed when they were out of view.

Planar Occlusion Optimization
- Using 3D planar mathematics, I calculated whether the player was positioned behind the mirror relative to its surface normal. If the player was behind the mirror, I disabled the mirror's rendering logic entirely, preventing redundant computations. This check was performed using a dot product between the player's position vector and the mirror’s normal, allowing for an efficient and scalable solution.

By combining frustum culling and planar occlusion checks, I significantly reduced the performance impact of real-time reflections while maintaining visual fidelity. This approach ensured that the mirror only rendered reflections when absolutely necessary, optimizing GPU workload without sacrificing realism.

Unfortunately, as I was refining this system, the team leads made the difficult decision to remove it from the project, as it ultimately did not align with the game's final vision.

Although it was challenging to let go of a system I had dedicated nearly four weeks to developing, I fully understood and supported their decision. Aligning with the project's overall direction was the priority, and I respected the rationale behind the choice.

Despite its removal, this experience was invaluable. I gained a deep understanding of how Unreal’s capture components function, how to effectively utilize render textures in materials, and, most importantly, how to optimize performance for real-time reflections. These insights have significantly strengthened my technical expertise and problem-solving approach.

Checkpoint based Save and Load system

I developed a checkpoint-based save and load system utilizing trigger boxes to store and manage player data. When the player reaches a checkpoint, relevant game data is saved, including position, progress, and key game state variables.

I will provide a comprehensive breakdown of the checkpoint-based save and load system, detailing its functionality and the individual components that contribute to its operation. This will include an in-depth explanation of each subsystem, covering how they interact to ensure seamless data storage, retrieval, and player respawning.

Player Save Data

I created a struct that stores in the following data:

Player checkpoint location vector
Player orientation rotator
Shard list integer array
Doorlocks name array
IsNotNewGame boolean
Player play time float
Shard Box transform

Saving system

I am using the built-in unreal function 'Save Game to Slot' to implement the save system. I created my own wrapper functions that call the built-in function.

Logic for saving player data

There are multiple cases where the player data gets saved within the game. There are 3scenarios where the player data gets saved:

When the player goes through a checkpoint trigger box
When the player places a shard on the shard box
When the player solves the door number lock puzzle

Checkpoint trigger save

Shard on shard box save

Door number lock puzzle save

Loading system

I am using the built-in unreal function 'Load Game to Slot' to implement the load system. I created my own wrapper functions that call the built-in function.

Logic for loading player data

There are multiple cases where the player data gets saved within the game. There are 3scenarios where the player data gets saved:

When the player continues from last checkpoint from main menu
When the player restarts from last checkpoint from the pause menu
When the player dies and restarts from last checkpoint

Continue from main menu

Restart from pause menu

Checkpoint restart from death menu

Logic for deleteing player data

Whenever the player needs to start a new game, the system needs to handle deleting all existing saved game data. Below is the implementation for deleting game data.

Level streaming system

During development, the design team structured the game into sub-levels, distributing the world into distinct sections to ensure the player remains within a single area at any given time. To optimize performance, I proposed and implemented a level streaming solution, dynamically loading and unloading sections of the game as needed. This approach significantly reduced memory usage and improved overall performance.

Below, I will provide a detailed breakdown of the level streaming implementation, explaining the techniques used to efficiently manage level transitions and resource allocation.

Level streaming volumes

The project contains 14 level streaming volumes. Every volume is attached to a sub level.

Sub levels

The project contains 9 sub-levels. Some of the sub-levels contain more than one level streaming volume to manage sub-parts of those sub-levels.

Below is a visualization of all the level streaming volumes in the project. All the volumes are highlighted in yellow.

An example of how level streaming volumes are attached to a sub-level.

There are 6 level streaming volumes attached to the sub-level 'Map_Section1'. What this means is that the sub-level itself is quite big and so needs multiple volumes to load and unload assets within it to keep the performance at a good level.

Game mechanics I worked on

I also had a chance to work on some game mechanics in the game. The 2 mechanics I worked on thats in the game are:

Throwable brick
Breakable glass

Throwable brick

I implemented a throwable brick. The main usage of this item is distract the enemy and this mechanic is deigned for stealth purposes. The brick makes noise whenever it hits something in the world.

Picking up the brick

Throwing the brick

Using unreal's built-in physics to add impulse force to throw the brick in the direction the player is looking at.

Brick hit logic

Breakable glass

I implemented the breakable glass system as part of the stealth mechanics. It works in conjunction with the brick. Throwing the brick at the glass will shatter it and make a lot of noise attracting the enemy's attention.

I am using the chaos physics system provided by unreal to implement the glass shattering logic.

Initializing the glass object

Updating the glass object per frame

PROJECT RETROSPECTIVE

WHAT WENT WELL

Minimal conflicts within the team
Flexible development and production pipeline
No off hour work
Made a fun and super engaging product in the end

WHAT WENT WRONG

Lack of buy in
Lack of communication between disciplines
Occasional miscommunication between leads
Last minute changes before milestone deliverables led to broken builds

WHAT I LEARNED

Collaborating across different disciplines presents more complexity and unpredictability than initially anticipated
Developing the ability to accept rejection from leads when they decline a pitched idea
Learning to separate personal investment from professional decisions when a system you created is cut for not aligning with the game's vision

Anishva Bardhan

Graphics Programmer