My Contributions

This project had some communication struggles — our designers were making placeholder scripts that other systems ended up depending on before the proper implementations could replace them. A good portion of my time ended up being spent working around those constraints rather than building greenfield systems. That said, we shipped a working game, and had the opportunity to build some fun systems.

Interaction System

The interaction system lets the player interact with world objects by holding the E key. I used an IInteractable interface with default implementations and an abstract base class, making it easy to add new interactables with minimal boilerplate. The player side raycasts each frame, focusing and unfocusing targets as they enter and leave view, and displays a progress indicator as the interaction timer fills.

Putting Out Fires

The PrototypeTimer - originally a designer script for tracking dungeon time - had become the de facto game manager by the time us programmers joined the project. Attached to the player HUD, it was coupled deeply to nearly every other script the designers had made. I'm not going to pretend that was ideal. In the final week of the project we experienced a string of build errors and crashes originating from this PrototypeTimer which the other programmers and myself somehow managed to get under control, though we never made the time to fully understood it. It was like an eldritch being, and I was not about to tango with Cthulhu.

I reworked a Puzzle Manager script (origninally made by a designer) which handled puzzles and opening doors across the level. Along with refactoring to make the code readable and maintainable, I added a system to let the player see which door opened when a puzzle was solved.

Sender/Receiver System

I made this system after seeing the puzzle solution that was already in the project. Using the observer pattern, senders broadcast events that receivers subscribe to, completely decoupling the two sides. The receiver uses a percentage threshold across multiple senders, making it easy to configure puzzles that require, say, two of three pressure plates to be active simultaneously. In the end we decided not to attempt untangling the spaghetti that was already there (which would be a herculean task), so the system saw little use.

Item and Inventory System

I built a data-driven inventory system using ScriptableObjects, so designers could create new items without touching code. Items sit in an ItemStack abstraction that handles both single items and stackable quantities cleanly. Towards the end of the project, this system was scrapped as it was deemed unnecessary for the game concept. Nonetheless, it was good practice in building extensible systems.