Game engineering, graphics & interaction design
Backrooms Escape
A 3D Backrooms puzzle horror game built with C++ and OpenGL, featuring logic puzzles, enemy pathfinding, audio pressure, etc etc
Backrooms Escape is a playable 3D puzzle horror game built around one simple feeling: being trapped inside a place that looks repetitive, quiet, and almost familiar, but keeps asking you to think while something is getting closer.
This is not only a scene, mockup, or graphics experiment. It is a small complete game: there is a main menu, intro flow, first-person movement, puzzles, enemy chase, audio feedback, final code, key pickup, ending sequence, and an escape condition.

The project started as a graphics and interactive techniques final project, but it became more than a rendering demo. It became a small game system where movement, lighting, maze layout, puzzle rules, enemy pathfinding, audio, and presentation all had to support the same escape flow.
The player explores a Backrooms-style maze, solves four puzzles, collects four digits, finds the exit key, enters the final code, and escapes through the final portal.

The problem
Small 3D projects often become either visual demos or mechanics demos. They can show a camera, a maze, or a shader, but the player does not always have a strong reason to care about what is happening.
For Backrooms Escape, the challenge was to make the technical parts feel like one playable experience. The project needed to demonstrate graphics concepts, but it also needed pacing, pressure, feedback, and a reason for the player to move through the space.
That meant every system had to do more than exist.
- The maze had to feel confusing without becoming unreadable.
- The flashlight had to help the player while also making tension more visible.
- The puzzles had to be simple enough to present, but real enough to have rules.
- The enemy had to pressure the player without requiring an overcomplicated AI.
- The final lock had to make the whole route feel connected.
The system
The desktop version is built with C++17 and OpenGL. The main game loop handles input, update, rendering, audio, and scene state, while the rules-heavy parts are split into smaller modules so they can be tested without opening an OpenGL window.
The project has several layers working together:
- 3D world - a grid-based Backrooms maze rendered with floor, wall, ceiling, texture, fog, lighting, flashlight, HUD, and horror overlay.
- Player controller - first-person movement, sprint, jump, stamina, flashlight battery, camera direction, and collision against the maze grid.
- Puzzle systems - 8-puzzle, Tic-Tac-Toe minimax, Minesweeper, Projection Align, and the final lock code.
- Enemy pressure - a billboard enemy that tracks the player through the maze using pathfinding and speed pressure.
- Audio layer - ambience, footsteps, chase sound, flashlight click, success feedback, battery warning, and jumpscare sound.
- Presentation support - intro slides, BTS demo files, documentation, screenshots, and a technical presentation deck.
The important design decision was keeping the logic explainable. Puzzle rules
live in PuzzleSystems, enemy pathfinding lives in EnemySystem, audio lives
in AudioManager, and gameplay constants live in GameConfig.
That made the project easier to present because the code was not just one large OpenGL file trying to do everything at once.

Why Backrooms
The Backrooms work well as a game constraint because the world is supposed to feel repetitive. A maze made of similar walls, dirty carpet, low light, and fluorescent ambience already belongs to the theme.
That gave the project a useful direction. Instead of building a large detailed environment, the focus could stay on space, visibility, navigation, and pressure.
The player does not need a complicated story to understand the goal. They are in a strange room system, there is an exit, and something in the maze does not want them to leave.
That simple premise helped the technical parts feel less abstract.
Puzzle flow
The escape route is built around four puzzle stations. Each puzzle gives one digit for the final code:
- 8-puzzle gives
3. - Tic-Tac-Toe AI gives
7. - Minesweeper gives
4. - Projection Align gives
1.
Together, the digits form the final code: 3741.
Each puzzle uses a different kind of thinking. The 8-puzzle is spatial ordering. Tic-Tac-Toe uses a minimax opponent. Minesweeper uses clues, flags, and reveal logic. Projection Align connects directly to the graphics course material by asking the player to choose the correct projection and view.
The final lock makes the puzzles feel connected. The player is not solving separate minigames just for score. They are building the key to escape.

Enemy and pressure
The enemy is intentionally simple: it is a billboard creature that moves through the maze toward the player. The desktop version uses BFS pathfinding across the maze grid, while the browser vertical slice uses A* for a presentation-friendly web version.
The pressure comes from how the systems stack together.
When the player moves, footsteps and stamina matter. When the flashlight is on, visibility improves, but battery becomes a resource. When objectives are completed, the enemy pressure can rise. When the chase audio starts, the maze feels smaller.
The enemy does not need to be complex to be effective. It just needs to make the player care about distance, sound, and time.


Visual and audio direction
The visual direction leans into the familiar Backrooms language: yellowed walls, dirty carpet, ceiling panels, low visibility, and fog. The goal was not to make the environment beautiful. The goal was to make it readable, tense, and useful for gameplay.
The assets support that loop: wall grime, torn wallpaper, floor stains, puzzle panels, flashlight overlay, exit key, exit doors, intro slides, and ending images.
Audio does a lot of the emotional work. Ambience keeps the space alive even when nothing is happening. Footsteps make movement feel physical. The chase loop and jumpscare sound make the enemy feel present before the player fully understands where it is.

Web slice
Backrooms Escape also has a browser-playable vertical slice in web/. It is not
an Emscripten port of the C++ desktop game. It is a separate remake using
TypeScript, Three.js, WebGL, Vite, and pnpm so the project can be deployed as a
static site.
That version keeps the core presentation route: start the run, move through the
maze, solve key puzzles, pick up the exit key, enter 3741, and reach the
ending sequence.
The web build made the project easier to share because people do not need to compile the C++ version just to understand the experience.

What I learned
Backrooms Escape taught me that a game project becomes easier to explain when the systems are separated by responsibility. Rendering, movement, puzzles, pathfinding, audio, and configuration all touch each other, but they should not all become the same piece of code.
The best part was seeing course concepts turn into player-facing moments. Projection is no longer just a camera setting. Pathfinding is no longer just a graph algorithm. Lighting is no longer just a shader uniform. They become things the player notices because they affect survival, navigation, and escape.
The game is small, but the loop is complete:
explore, solve, get pressured, collect, unlock, escape.
That complete loop is what made the project feel like an actual game instead of only a technical assignment.