The Unrealtor is a mind-bending 3D local co-op puzzle game where prospective tenants Noah and Maya use optical illusions to escape a surreal maze of profit-hungry renovations.
This game currently in production with a team of 25+ USC Games students as a part of the Advanced Games Project (AGP) class starting May 2025. It is being developed in Unity.
Role: Lead Engineer
Tools: Unity, Cinemachine, DoTween
As Lead Engineer, I am...
Leading an engineering team of 4 to code puzzle mechanics, character controls, and level flow; manage tasks per sprint; communicate with all disciplines to integrate assets and interpret spec sheets.
Writing systems for screen image matching, game state management, and level progression feedback.
Assisting other engineers in debugging issues and version control conflicts.
My programming focus in the project is designing and implementing major systems. A major consideration is creating systems that talk to each other but aren't dependent, especially for puzzles. Another is creating code that is modular and designer friendly
Match System:
MatchManager
Main hub for all match logic
Checks for matches from NearbyMatches by comparing how horizontally close the vertices are to the middle + how close the vertices are vertically close + angle between the player and quad
Handling visual and audio effects after match is complete, including Cinemachine camera transitions to show the ideal combined image to players
Handles Player input “submitting” a match
Contains A simple state machine for match hints and visual feedback
Contains all info per match: thresholds for checking for a match, events, cameras, data on what happens after the match is completed
Contains a Left and Right QuadBase
In each MatchBase, there should be one Left QuadBase and one Right
Contains basic quad information
Has a collider that adds/removes the quad from the NearbyMatches list
Puzzle System / Behavior Graph:
All puzzle elements (matches, doors, etc) inherit from PuzzleBase
Each puzzle has its own Behavior Graph and uses EventChannels to communicate, instead of a centralized system
I used Unity's Behavior Graph (which currently has very little documentation) to create node-based logic for determining when a puzzle is completed or available. A big challenge was working around the limitations of the current system. For example, the Behavior Graph doesn't allow variables that are lists of a specific class type, only primitive types and GameObjects.
Some nodes I implemented include: AND and OR gates (compares a list of GameObjects), an EventChannel to handle when an event was completed, the ability to trigger other puzzles/door opening