Coding Frosthaven: The Tech Behind the Tabletop Shift

Bringing a massive tabletop game into the digital space requires honoring the original physical experience as well as leveraging the raw power of a digital engine. When a studio led by Julian Gollop—the legendary creator of X-COM and CEO of Snapshot Games—takes on a mammoth project like Frosthaven, we naturally want to see how the engine purrs under the hood. Recently, we had the humble opportunity to sit down with Hristo Petkov, Game Director of Frosthaven, alongside deep insights from the studio’s CTO, Sergey Georgiev. We wanted to understand the architectural challenges as well as technical breakthroughs required to adapt this complex analog system into a sprawling digital RPG.

Taming the Calendar: Tracking a Shifting World

Frosthaven introduces a dynamic calendar system, complete with shifting seasons and evolving outpost structures. Tracking these long-term world changes across a 130+ quest campaign without bloating save files or causing performance degradation is a major backend hurdle. The team’s solution, it turns out, relies on elegant simplicity.

Hristo & Sergey: The calendar is just the current number of “days” and a basic list of events and their trigger conditions. When you trigger something that needs to happen in the future a new event is added to the list. When the “days” advance you check the list if the time for a given event is due and trigger it if needed. The events are stored as basic IDs so the serialization is pretty efficient.

The Problem with Advantage Ambiguity

Translating ambiguous human judgment into hard code is notoriously tricky. In the tabletop version, players resolve “Advantage Ambiguity” during card draws with a quick visual judgment or a peek at the rulebook. Automating this digital edge case to evaluate consistently forced Snapshot to rethink their turn sequencing.

Hristo & Sergey: Advantage Ambiguity refers to the fact that in the board game when a player has advantage they draw 2 modifiers and choose which one to use. In the digital version initially we did the choosing for them by arguably choosing the better one for the situation but that limited the freedom of the players where in some corner cases the better one was not the one they wanted. That is the reason we implemented the feature to let the players choose for themselves. It was a technical hurdle because we needed to implement a new step in the flow of the turn to be able to achieve that.

Bending the Rules: The Impact of House Rules

The 1.0 release proudly introduces “House Rules,” but opening up underlying game variables to players is risky. We’ve seen plenty of games where toggling core tactical parameters corrupts campaign logic or breaks AI scripting. Snapshot had to build the game’s rule engine to remain stable and isolated even when players start tinkering.

Hristo & Sergey: There are two types of house rules – campaign rules and game rules where the campaign rules are set when the campaign is created and cannot be changed and game rules which can be changed all the time. An example for a campaign rule would be Iron Man mode, starting with one save and one save only it will not be ok to change this on the fly, same goes for separate resources per hero or combined resources for the party. Both examples are something that will break the game if we switch it on the fly where there are other things like for example switching the x2 and x0 modifiers to be +2 and -2 is something that can be switched on and off seamlessly without causing issues.

Mastering the Blinkblade’s Temporal Mechanics

Classes like the Blinkblade add another layer of mechanical complexity. Relying on a fast/slow state mechanic that alters card initiatives and abilities on the fly requires careful coding. We were fascinated by how the team ensured this dual-state logic wouldn’t clash with external status effects and monster initiatives inside the turn-sequencing engine.

Hristo & Sergey: The slow/fast mode of the Blinkblade is a condition. Each ability in the cards has a “conditional override”, which changes the ability depending on what condition is currently active on the Blinkblade.

Quality Assurance at Scale

Moving from a handful of quests in Early Access to a full 130+ quest campaign creates an exponential web of variables. With endless character combinations and items, tracking down game-breaking event triggers or map geometry flaws in late-game acts is a daunting task. To handle this, the team had to figure out where automated testing made sense and where human eyes were irreplaceable.

Hristo & Sergey: We have automated testing for levels and art assets that checks for broken environment and character prefabs, texture issues or framerate issues. Gameplay (with small exceptions) is almost entirely manually tested. Currently there’s an ongoing effort for automated testing of character cards.

Holding Back the Final Hero

Certain elements, like the elusive “Final Hero” and specific new building functionalities, were intentionally held back until the official 1.0 launch. It’s easy to assume this was due to core technical dependencies or deep mechanical complexities that required these pieces to wait for the final build. But the reality was a bit more straightforward.

Hristo & Sergey: It was not a technical decision but mostly for the sake of consistent storytelling. With that said every hero in Frosthaven is its own beast with this one being no different.

Battling Information Overload with the Codex

Digital board game adaptations frequently struggle with information overload, and a major feature of Frosthaven’s 1.0 release is the fully implemented Codex. The UI team faced the tough job of balancing information density—ensuring players have immediate access to deep mechanical references without burying the active tactical screen in endless sub-menus.

Hristo & Sergey: It was and is still is an ongoing effort but our philosophy was to hide as much information as possible (being accessible within 2-3 clicks) and then check the feedback from the players to see what is really needed to be present at their fingertips and what is more of a rare case. We started with many things hidden and slowly brought back the most important ones. This process is still ongoing and is probably the most challenging part of the game so far.

Translating the Tangible

The original tabletop experience heavily relies on physical envelopes, stickers, and secret puzzle books to handle quest-related assets. Snapshot worked extensively on “Inspectable Quest-related assets” to capture that feeling. Translating that tangible sense of physical exploration into a clean, intuitive digital interface required a very specific design approach.

Hristo & Sergey: Compared to the board game we had the benefit that we could create unique assets for every important object but that was not enough. In this game there are a lot of rules that are effects that are not easy to understand at first glance and the player needs to take the time to grasp them. What we can do and we did is to present the information in a way that is easy and intuitive to access.

Keeping the Party Synced: Multiplayer Challenges

Co-op multiplayer is where the technical load gets particularly heavy. Syncing intricate turn resolutions, modifier deck shuffles, and complex status interactions across up to four players is no small feat. Keeping client states completely synchronized when multiple players chain complex card combos simultaneously required some major engineering breakthroughs behind the scenes.

Hristo & Sergey: The game uses an authoritative server that replicates the game state to clients. This, in theory, should ensure that the clients receive the same game state and see the same events happening in the same order. In practice, since the client’s GUI can be in a different state when receiving the updates from the server, race conditions can occur that will mess up the local game state and desync the client from the server. These are extremely difficult to reproduce and having a very comprehensive logging of what each client is doing is essential. When reporting issues and the game is in multiplayer mode, it collects the logs from all the clients and uploads them to our issue tracker as well with a full server state and a save game which later gets analyzed to see what actually caused the desync. There is also a lot of debugging code that’s running in our development builds that tries to isolate and catch issues like that.

The Golden Rule of Digital Adaptation

For indie teams looking to adapt massive tabletop systems, avoiding technical debt is the ultimate boss fight. Making the wrong architectural choice on day one can crush a project later in production. We leave you with Hristo and Sergey’s hard-learned advice for developers embarking on similar digital adaptations.

Hristo: From my perspective the hardest part is understanding what the constraints are. You should not just start writing systems without knowing what to expect in the future. We have the luxury to have the whole design of the board game in front of us. We just need to dissect it and structure it for our needs. With that said there are always unexpected situations that occur and we should be flexible when that happens.

Sergey: You can separate the game into systems and content. Systems are serialization, multiplayer, screen and world space GUI, gameplay and AI, etc. Content is the levels, characters, abilities, concrete GUI elements, concrete AI behaviors, etc.

The general principle is, don’t create a lot of content before you have a pretty good idea what the systems for that content are needed and what the pipeline for creating that content is.

If you, for example, start working on abilities before having multiplayer sorted out, you may need to add multiplayer support for a lot of already created abilities that don’t care for multiplayer. This is usually much slower than writing the multiplayer system first and then creating all the abilities with multiplayer in mind in the first place.

Using placeholders for systems and art assets does wonders until you have a pretty good idea what the final game will look like.

This approach is not always possible, especially when you have tight deadlines and constant pressure to deliver working builds. Still, it is always good to spend some time thinking about what the final version of your content will look like and what the process of creating it is.

Another thing to consider with games with a lot of gameplay content is not to generalize. It’s tempting to have a declarative system in which you can define abilities with a few keywords. This usually ends in a big mess and giant god systems that handle hundreds of corner cases. Instead, just program the abilities in a scripting language and when you see that some patterns emerge you can always put those in helper functions. A hybrid approach with a declarative system that supports some programming features is also a possibility.

From what we saw, adapting a behemoth like Frosthaven is clearly no small task. As Hristo and Sergey illustrated, it is a constant tightrope walk between respecting the physical game’s intricate and engineering robust digital systems that can carry the weight of a massive campaign. Snapshot Games has proven that with the right architectural foresight and, of course, a willingness to adapt, even the most daunting analog systems can thrive.

Thank you for reading! Before you leave, though, we have a question for you too! Are you jumping into the 1.0 release with your friends, or is there another heavy tabletop RPG you’re dying to see adapted into a digital format next? Let us know down in the comments!