Paccarat is a roguelike multi-deckbuilder where players recruit a rag-tag team of rats and craft a curated deck for each, discoverating devastating multi-deck combos.

The demo for Paccarat is available on Steam.

I served as the Lead Software Developer contributing to nearly every aspect of the game's technical development. My responsibilities included designing and implementing core gameplay systems, guiding and collaborating with other developers, building and iterating on UI using Unity's UI Toolkit, planning development sprints around major milestones, managing builds, and preparing releases for Steam. Below are several of the major systems and features I developed, along with details on how they were implemented and the design considerations that informed their architecture.

Early in development, we knew it would be critical to iterate quickly on cards and abilities. Designers needed the ability to experiment with new ideas without requiring frequent code changes. While the team had created some early prototypes, they still required too much engineering effort whenever a card needed a new variation or unique behavior.

With these low level building blocks identified, I designed an effect system inspired by AWS Step Functions, where each card or ability effect is represented as a workflow composed of modular steps. Each step performs a single operation and passes information forward through an Effect Document (a shared key-value data store), which acts as a shared data container for the workflow.

The sequence of steps that define a card's behavior is configured directly in the card's ScriptableObject inspector, allowing designers to assemble complex effects without writing code. Each step declares the values it reads from and writes to within the Effect Document. Internally, the document stores data using maps for primitive types such as strings and integers, as well as a custom generic list dictionary that allows generic objects to be passed between the steps when needed. This approach sacrifices some compile-time type safety, but it provides the high flexibility needed for a highly data-driven system.

This system made it possible to create highly varied cards while keeping the underlying implementation modular, extensible, and designer-friendly.

To support both keyboard and controller navigation, I implemented a custom FocusManager that handles focus and input routing across both worldspace GameObjects and UI Toolkit VisualElements. Each focusable object registers itself with the FocusManager. Worlspace objects and UI elements each have thier own focusable component responsible for handling callbacks when an element gains or loses focus. The FocusManager maintains the global focus state while each individual focusable component is responsible for their own behavior when gaining or losing focus. Below are the core capabilities of the FocusManager.

This system allowed both worldspace gameplay elements and UI Toolkit UI to share a consistent navigation model while remaining flexible enough to support complex UI state.

For Paccarat's UI we chose Unity UI Toolkit, which Unity has set up as the long-term replacement for uGUI. Because our team already had experience with web development, UXML + USS workflow made UI iteration fast and intuitive.

To keep the UI logic organized and avoid tightly coupling gameplay code to individual UI elements, I implemented a ViewController pattern inspired by MVC.

Each UIDocument (or major VisualElement with a document) is wrapped by a dedicated ViewController script. The ViewController owns the root VisualElement and acts as the single point of contact for all interactions with that UI.

Views are responsible for managing their own internal state and determining when elements should be active, visible, or updated.

The parent view implements the delegate interface to define appropriate behavior, allowing the sub-view to remain reusable and context-agnostic.

By default, UIDocument content renders after the rest of the scene, meaning it always appears on top of world elements. This became a problem because some core parts of theg ame, including the combat scene, are implemented almost entirely in UI document. We also wanted certain visual effects to appear above specific UI elements, which is difficult with UI Toolkit's default rendering pipeline.

To solve this, we render the UI Toolkit output to a Render Texture, then display that texture on a RawImage inside a uGUI Canvas. This allows us to use traditional sorting layers and render order control, while still building the interface using UI Toolkit. This hybrid approach preserved the flexibility of UI Toolkit while allowing the game's VFX system to integrate naturally with the UI layer.

While this hybrid appraoch adds an additional rendering step, it allowed us to retain the felixibility of UI Toolkit while still integrating with the game's existing VFX and sorting layers.

Before working with UI Toolkit, I personally had very little experience with web development (but the rest of our team did). Working with UI Toolkit has truly helped me learn the major components of page layouts and stylesheets, enough to be able to build this website from scratch.

From early in development, I wanted to lean into Unity’s component-based architecture and maintain a clean separation between scenes. A common approach to sharing state between scenes is to create persistent manager objects using DontDestroyOnLoad, but this often requires a dedicated initialization scene and can tightly couple scene loading order to game state setup.

Instead, I implemented a ScriptableObject-driven persistence layer to maintain game state across scenes. Key pieces of runtime state, such as player data, the current map, and encounter progression, are stored in VariableSO objects. Once loaded into memory, these ScriptableObjects persist across scene transitions, allowing scenes to read and update shared state without requiring persistant GameObjects.

This approach enables clean scene transitions where a scene simply updates the relevant state and loads the next scene. Because the sate lives outside of any particular scene, this avoids complex initialization logic, multi-scene loading setups, or fragile cross-scene references.

Another benefit of this architecture is improved development workflow. Developers can load directly into any scene in the game withoout needing to first run an init scene. To support this workflow, I helped build a suite of custom inspector tools for the state ScriptableObjects. These tools allow developers to quickly inspect and modify runtime state directly from the editor. With a single button press, the system can analyze the current scene and automatically configure the required state objects so that the scene runs correctly in isolation.

This system keeps scene logic modular, simplifies debugging, and significantly speeds up iteration when testing individual gameplay scenarios.