Monster Tea Time
Monster Tea Time is an in-development capstone project created as part of my Master’s in Game Design and Development program at RIT.
​
In this cozy island life sim, players take on the role of a human who finds themselves stranded on an island inhabited by monsters that despise humans. To survive, and perhaps even thrive, the player must assimilate into monster society by learning their customs, gathering ingredients, and brewing tea for the island’s quirky inhabitants.
Through these small acts of kindness, players gradually build trust, form meaningful relationships, and uncover the heartwarming story of bridging two very different worlds.
Team Role
Gameplay Network Programmer
As part of Team Cozy Cryptids, I serve as the Gameplay Network Programmer for our capstone project. My primary responsibility is to ensure players can seamlessly visit each other’s islands and interact together in a shared environment. I help design and implement systems such as the inventory, minigames, crafting, and NPC behaviors with a network-first mindset, ensuring they are fully synchronized and multiplayer-ready. Additionally, I develop tools, helper functions, and abstractions that streamline the networking workflow, making the development process smooth and efficient for the entire team.
Network Architecture
Our team aims to publish Cozy Cryptids on Steam by the end of the academic year to share our hard work with players and offer a cozy, relaxing multiplayer experience that friends and families can enjoy together. To support this goal, we plan to integrate Steam’s API services into our project to enable features such as friend invitations, lobby creation, and matchmaking directly through the Steam platform.
​
Given the casual and social nature of our game, and the size of our development team, we’ve chosen to implement a host-client architecture. This approach allows one player to act as the host, with friends joining their island to hang out, play minigames, and relax together in a shared environment. Networking will be powered by Steamworks services, which handle essential transport and connectivity tasks such as relay servers, lobby management, and NAT traversal, while also providing built-in support for Steam platform functionality.
​
To integrate these systems into Unity, I’m using Facepunch, a robust C#/.NET wrapper for the Steamworks API, alongside Unity’s built-in networking tools to handle the game’s netcode logic.. Facepunch offers a developer-friendly interface that simplifies communication between Unity’s networking layer and Steam’s backend systems. By leveraging this library, I can focus on designing network-agnostic gameplay systems and ensure seamless multiplayer connectivity, minimizing the technical overhead for the rest of the team while maximizing stability and ease of use for players.
Code Architecture
One of the primary challenges in this project is that the game is designed to be a primarily single-player experience that also allows friends to join in seamlessly. Players should be able to invite others to their islands, hang out, and participate in activities—without having to reload scenes or maintain a constant online connection. Our goal is to let players freely transition between solo and multiplayer modes, whether they open their island to public visitors or invite specific friends.
​
This design introduces a unique complication: many systems must dynamically shift their behavior depending on whether the game is running in single-player or multiplayer mode. In single-player mode, we want to avoid maintaining an unnecessary network connection or syncing network objects in the background. However, when the player transitions online, all relevant systems should adapt to a connected state and begin synchronizing as needed.
​
To address this, I implemented a service-based network architecture. Each multiplayer system in the game is accessed through the MultiplayerServices container, which provides interfaces for key features such as object spawning, trading, and player management. Each of these services has two implementations: a Local Service and a Network Service. Both derive from the same abstract base class and share a consistent API, ensuring that the rest of the game logic can interact with them interchangeably.
​
For example, when the game needs to instantiate an item in the scene, it calls the Spawn() method through the Spawner Service. If the player is offline, the LocalSpawner simply instantiates the object locally and attaches a NetworkObject component to prepare it for future synchronization. When the player transitions online, this local instance can then be registered with the network session. Conversely, if the player is already online, the NetworkSpawner immediately spawns and synchronizes the object across all connected clients, ensuring everyone has a consistent copy.
This service-swapping approach allows gameplay systems to remain network-agnostic—they don’t need to care whether they’re in a local or networked context. It also simplifies testing and maintenance, since developers can work on individual systems offline without needing to run a full multiplayer session. The architecture promotes scalability and clean separation of concerns, providing a strong foundation for future features like drop-in/drop-out multiplayer and persistent world states.
This project is currently in active development. Stay tuned for future updates. Follow our socials to stay informed of our latest updates.
.png){kind=logo}
