Last month Morgan described our efforts to improve and update the Roll20 experience on the VTT and tackle performance in a big way, writing “it’s 2022 now and we’re ready for change.” Well, we’ve taken the first steps in that journey, so let’s talk about how we’re doing it and what we’ve done.

We’re calling the team working on performance and stability “Operation Fire Bolt,” a group with three major user experience aims:

  • Less time waiting for things to load
  • Better performance with less memory and CPU used
  • More reliable virtual tabletop, character sheets, and dice rolling performance

This will be the first in a series of posts to keep you all informed about our progress and what we’re planning to work on next. First up: On-Demand Character Data Loading.

On-Demand Character Data Loading

In the past, we loaded all character data (hit points, spells, items, etc.) all at once on game load to the virtual tabletop, contributing to a longer initial wait. We now load character data for individual characters when you need them, massively reducing initial load time and memory usage.

You may have noticed this change as one bullet point among many outgoing fixes and features in our Change Log last week (lots of good reads in there), or you may have noticed the 57% reduction in-game load time this weekend. Don’t worry; this blog post will wait if you want to load into a game and test it—you’ll see the most noticeable difference in games with a lot of character data like Pathfinder’s Rise of the Runelords or Dungeons & Dragons’ Dungeon of the Mad Mage, where character data constitutes 80% or more of a game’s total data.

The developers involved in this project have solid infrastructure chops, so coupled with the cool team name, we’re expecting great things. In fact, I’ll let Jeff, senior developer, Fire Bolt team lead, and gunpla enthusiast describe some of the key impacts this project will have on your Roll20 games.

Hi! I’m super excited to chat about some of the improvements and performance optimizations we’ve made. First, On-Demand Character Data Loading; here’s some of the main benefits we’re already seeing now:

  • The amount of data initially loaded by your browser is considerably reduced (Dungeon of the Mad Mage went from 500MB RAM consumption to below 200MB on initial load), which will have a general performance impact as well as substantially reduce the time to load the game.
  • Initial Game Load Time—or, how long it takes to go from “Launch Game” to actively playing—has been massively reduced across the board. The vast majority (95%) of games load up to 50% faster. If you have a big game with lots of characters, it should be a lot faster to get in and play. 50% of all games load in under 4 seconds.
  • Our Firebase Real-time Database instances now need to transmit 60% less data on average, which means their response times are increased across the board, resulting in a marginal, but noticeable increase in how fast your game in the VTT responds to changes other players make.

We’ve been sharing one particular graph on our dashboard a lot, and I want to show it to you all, too; this is a graph of how much data is transferred over time for the virtual tabletop. This is a graph of last week (the week of Monday, March 21, 2022), and I’ve marked when on-demand character data loading was released. The dotted line is a comparison to the previous week, in the “before times,” when we loaded everything at once!

Technical Details

If you’ll indulge me for a moment, I’ll talk a little bit about the technical details. Lazy loading is a change to the backend of the VTT that we’ve wanted to work on for quite a long time, but there were many difficulties in real implementation. The biggest hurdle is that all of the code on the VTT and elsewhere (like in the API sandbox) assumes by default that all the data will be present. There’s quite a lot of code that was simply unprepared to wait for data to arrive on-the-fly.

If you’re familiar with JavaScript, you might know about Promises—most of the code written for things like macros and character sheets was written before Promises even existed, and all of that needed to be adopted, retrofitted, or reworked to function within an asynchronous framework. As you might imagine, keeping all of that working as it originally functioned while changing a lot of the functionality under the hood is a pretty big undertaking. The groundwork we made here is just the start of further improvements coming down the road, and I’m very excited to be working on them and sharing the details with you. Back to Ashton!

What’s Next for Operation Fire Bolt?

If we rolled for initiative last month, this month we landed a critical hit to improve performance for our users on the virtual tabletop. We’re proud you can get to slaying dragons, rescuing princes, and rolling a thousand d20s (we see you) faster than ever. This is just the first step, though, so let’s talk about those d20s. One of Operation Fire Bolt’s next aims is getting you your dice results faster. Note that we said your rolls will be faster, not better, so until quantum fluctuations take bribes you’ll have to take your Nat 1s up with the universe.

You’ll hear more from us soon.

Ashton Duncan Product Manager

Ashton Duncan started as a Roll20 content conversion contractor with Curse of Strahd five years ago and is now a product manager. She writes and edits D&D 5e and independent TTRPG adventures, rulebooks, and supplements in her free time. The material components in her summoning spell are an oat milk latte and a high fantasy novel. Follow her on Twitter @ashtonnduncan for video game deep lore and pictures of her dog.