Guilds of Greybrook
Guilds of Greybrook is a student project that got an honorable mention in the Collegiate Games Challenge. I joined the project as a programmer while it was still a class project to transfer the physical card game prototype into a digital game. I later continued development in the summer of 2025 to add key features needed for a Steam release, like saving and loading.
Contributions
Programmed core game systems (cards, quests, tooltips, save, and load)
Designed and programmed the majority of user interfaces and front end systems
Worked closely with artists to implement assets under constraints of the game
Tooltip System
In a card game, efficient communication is essential for a smooth user experience, and during the early stages of development, there were a lot of numbers and symbols without context, making playtesting difficult.
I created a tooltip system to be used by other programmers and designers to allow for smoother player communication. This included banners that can appear at the top of the screen in response to in-game events and adaptive text boxes that appear when hovering over different elements.
Though this served its purpose for the prototype version of the game, I later expanded this system after studying the user experience of other digital card games, like *Slay the Spire* and *MTG Arena*, to have the hovering popups appear in self contained text bubbles adjacent to the UI element.
Flexible Card System
Originally patterned after this Mix and Jam video, the card system has been optimized and expanded for use in a larger project.
The `Card` base class is responsible for holding all logic associated with card interaction. Subclasses of `Card` holds any needed data the card represents, whether it be an item, a member, or quest. The `CardVisual` class reads the data off of the card to produce a user facing display of relevant information, as well as any juice with the movement separate from basic card interaction.
All the data for the cards are stored independently as scriptable objects, meaning there is only one required prefab per unique card type that acts as a vessel to hold and display data to the user. This pattern makes it simple to add new features to specific card types without the concern of breaking others.
Saving and Loading
As the game grew in scope, players wanted to save the game and return later. Also, for testing purposes, it was useful to have the ability to return to a bugged run of the game for hard-to-replicate issues.
Fortunately, the way the card system was architected allowed the game state to be replicated with only essential data and no Unity MonoBehaviours, meaning everything could be stored and serialized in a single struct.
Deserializing the data from the struct was trickier because there was persistent data (such as which members had been fired) that didn't have associated Unity game objects in the scene but needed to be applied to specific cards. This was solved by having an internal list of all available member data that could be overwritten by only the data that changed from save to save.
A demonstration of a full run of Guilds of Greybrook
© 2025 Langston Key
•
contact at keylangs@msu.edu