Digital TTRPGs

A while ago I was nerd–sniped by Dice Goblin's post, shortly followed by Dungeon Merlin's post. Both talk about the bane of my existence: PDFs.

Reading PDFs from a desktop computer is pain. If you have an external monitor, you can rotate it to a vertical position to make your life a little bit easier. However, on all other kinds of computers you are forced to read a vertical page on a horizontal display, which drives me nuts. In addition to the visual aspect, there is usually almost no interactivity built–in. Internal links connecting table of contents with some pages is usually the most there is.

My software engineer curse kicked in and I started spending lots of time thinking what could be done. Below is a collection of ideas I had. If any of those seem interesting to you, I would love to chat. Feel free to reach out on either Bluesky or hi@laplab.me.

1. Website for hosting TTRPGs

I don't like this idea for two reasons: huge legal maintenance burden and platform lock-in.

Maintaining a public service that handles user–generated content and potentially acts as a marketplace becomes less and less feasible. UK Online Safety Act and Collective Shout's actions have demonstrated that you can be screwed over real fast. I would much rather rely on existing platform like itch.io or Drivethrurpg to handle this.

I also don't think there is much trust to individual websites in the TTRPG space. Websites go up and down all the time. I know my share of TTRPG blogs that are only available on Web Archive now. Locking your creation to a specific website means you have to trust the person maintaining it to not become a fascist and accurately represent your interests. Building this trust requires a lot of time.

2. Single-file HTML pages

I don't think this will work from the technical standpoint. TTRPGs in my PDF collection range from 4MB to 218MB (looking at you, Trespasser). I'm sure the file size will be significantly smaller for HTML, but we are still looking at MBs of images baked into the HTML. Browser will definitely choke parsing all of this at once. Even if you include images as strings somewhere, these are still strings the parser needs to go through.

An alternative is to distribute a collection of files. Perhaps a folder of HTML files and images, so that we don't have to load everything all at once. This is, after all, is how websites work. I personally don't like this idea. It feels sloppy and very easy to mess up for the reader (like accidentally deleting a file in such folder).

Progressive Web Apps could be a solution, but these act more like a cached version of an existing website. This brings us back to option №1.

3. Desktop app

We can distribute TTRPGs in our own custom format and read it with an Electron app. This requires every reader to have this app installed on their computer. GMs, Referees and Conductors will likely install an app to read their favourite TTRPG. However, what about other TTRPGs? Is it worth "the effort" to install an app to check out this free game? It might sound weird, but that effort calculation is very likely to happen at least to some people. In a space that's overloaded with games and frankly doesn't have a lot of money in it, adding this extra step might be a serious limiting factor.

Except I don't think that whatever we invent here will replace PDFs. Instead, I see the new format as complimentary to existing ones. PDFs solve one problem really well — distribute content so that it is easy to print in a wide variety of environments. We don't need to solve this again. If the game includes both the PDF and whatever format we invent, this might smooth "the effort" calculation — checkout PDF quickly, download an app to read more comfortably if you want.

This, however, now requires distributing your game in two formats. For most of us creating TTRPGs is a hobby, so I'm not sure if anybody would do this double effort.

I have my reservations about Electron apps in general as well. They always look clunky, weird and take a few gigabytes of space. I'm not excited making something like that.

4. Offline web app

Some web apps work entirely offline. Consider Parquet Viewer: it's a web app that takes a Parquet file as an input and inspects it right there in the browser. It doesn't upload the file anywhere. After loading the page, you can turn off the internet completely and it will still work.

This approach combines single file HTML and Desktop app ideas. You have a single HTML page that can be hosted anywhere — doesn't need to be on one specific website. Don't trust the websites? Save it and open the HTML file on your computer.

This HTML file contains a viewer. Viewer doesn't need to load 280MB and it's not specific to any one TTRPG. Instead, it's a universal tool to read TTRPGs packaged in a custom format.

When you open a TTRPG in a viewer, it doesn't try to read the entire file. Instead, the file format is structured in a way that allows the viewer to only read small parts relevant to the current page. Doesn't matter if your TTRPG is 4MB or 20GB, the viewer will open it just fine without lagging.

This approach doesn't solve the problem of forcing the TTRPG authors to distribute the game in PDF and in this custom format. Unfortunately, I'm not sure there is a solution. We can definitely add the capability to print the pages from the viewer, but it won't look as great on print as something designed in professional software like Affinity Publisher.

Maybe instead we can make "the effort" step of opening a website and selecting a TTRPG in the file picker so smooth that distributing two files won't be necessary. If you ever plan to print your TTRPG, you still need to design a separate PDF for that. However, most of us only distribute TTRPGs digitally, for which not having a PDF is fine, as long as "the effort" to open a different format is not too much.

Closing thoughts

Making a viewer and a custom file format is only half of the story. We also need some way for authors to create TTRPGs in the new format. This will definitely require some UI and while file formats and efficient parsers are my area of expertise, frontend development isn't. My hope is that if we make the format open source, there will be someone in the community to help with that.

Let me know if you found this interesting! For now, I just wanted to share some thoughts — I don't have any prototype, but I already have ideas. If this leads nowhere, that's totally fine as well 🙃