Missing Picture

The clues’ backend was a core part of my work on world state‑saving. It connects to the map, camera, polaroids, world objects, and the board, ensuring each system can access consistent information about every clue. Because the game spans multiple scenes that the player frequently moves between, the backend needed to be lightweight, stable and easy for our designer to work with when adding or adjusting clues. 

To ensure this, I built the backend around Scriptable objects. This meant that our designer only needed to keep track of one component per clue to access the backend data, such as the name-identifier shown to the player when a clue was detected by the camera. Since each clue asset tracked whether it had been collected by the player, other systems did not need to save that information across scenes. Beyond this, I designed the surrounding systems so that our designer could use the same scriptable objects to control what in-world object was assigned to each clue as well as which clues could be used to solve each part of the mystery on the board.

The team wanted the player to feel free to photograph anything in the game's world, which meant the game had to potentially handle more than a hundred photos in a single playthrough. To support this without causing memory issues, I built the polaroid backend around a static list that receives data from the in‑game camera system. Each time the player takes a photo, the camera sends the image data and any detected clue information to this list. If a clue is detected, the image is also added to a static dictionary, and any older image of the clue is replaced to avoid duplicate polaroids. This kept the information available across scenes and made it straightforward for other systems to reference.

This pipeline also solved a major potential memory problem in the UI. The polaroid chapter in the book is a way for the player to browse through their taken polaroids, both while roaming the world and when solving the mystery at the board. Early versions generated a separate UI instance for each polaroid taken, meaning that there could be an immense amount of memory usage if the player took a lot of pictures. To avoid such a scenario, I rewrote the polaroid chapter to instead use one fixed set of polaroids which displayed the picture on a current index in the static polariod list. If the player hadn't taken enough pictures to fill out the entire page, the superfluous polaroids were hidden. This meant that the amount of memory used specifically for the polaroid chapter stayed consistent no matter how many polaroids the player decided to take.