Don T Let Auntie Mabel Bless The Table

The Quick Version Before You Waste An Evening

Don T Let Auntie Mabel Bless The Table is a narrative engine and table management toolkit built for small-party TTRPG sessions. It's not a replacement for a GM screen. It's not a character builder. It does one thing and tries to do it without getting in the way: handling the background noise of a session so the actual players and the people controlling the characters can stay focused on play. I've been running games long enough to stop trusting tools that promised to streamline things and ended up adding another layer of overhead. When someone first showed me this setup, I didn't think much of it. I've since used it through three campaigns and still keep it on my table. Here is how it works, where it trips up, and what I learned the hard way.

Setting Up Don T Let Auntie Mabel Bless The Table Without Losing Your Mind

The tool is distributed as a zip containing a single executable and a config folder. No installer. No launcher. Download it, unzip it into a folder you will remember, and run it from there. Do not put it in Program Files or on your desktop if you are on Windows, because permission issues will bite you later. Once it is running, you are greeted by a blank project page. This is intentional. It does not fill in defaults for you. I usually start by creating a new project, naming it, then immediately going into the config folder and editing the settings file directly instead of using the GUI. The GUI works, but it is slow on project load. The config file is plain text, and you can script changes across multiple projects at once if you ever need to. Before you import anything, check your system clock. I lost three sessions worth of narrative state once because the tool stores timestamps locally and my system had drifted by twelve minutes. It sounded like a bug until I realized what was happening. A simple ntp sync fixed it, but the corrupted state was already there.

How the Core Loop Actually Works

Don T Let Auntie Mabel Bless The Table revolves around three concepts: cues, threads, and noise. A cue is any trigger you define. It can be something as simple as a player mentioning a specific NPC, rolling a particular result, or reaching a threshold on an inventory slot. A thread is a continuous narrative line that persists between sessions. Noise is the ambient activity generator that fills the world around your players when they are not directly interacting with it. Here is the part beginners miss. The tool is designed to run passively. Most people treat it like a combat tracker and try to force it into active use during every scene. It works best when you set up a few cues and threads before the session, let it sit in the background, and only glance at it when a player asks what is happening in the city or when you need a quick random event. I track roughly six cues per session. Anything more and I spend more time managing the tool than playing the game. The noise generator has a quality problem out of the box. It produces repetitive output after about forty-five minutes of runtime. The workaround I use is to split the noise engine into two instances with different seed tables and switch between them when one starts cycling. It takes about ten minutes to set up the second instance, but after that it runs cleanly for hours.

Common Pitfalls With Don T Let Auntie Mabel Bless The Table

The biggest issue people run into is cue overlap. When two cues fire in the same timeframe and neither is marked as exclusive, the tool outputs both simultaneously. This creates a tangled narrative state that is very difficult to untangle later. I have spent twenty minutes in post-session cleanup trying to separate two merged threads that should never have intersected. The fix is to tag cues with mutually exclusive groups and enforce that at the project level. Go into the config and add the exclusion flag to any pair of cues that involve the same faction or location. It adds about five minutes to setup, but it prevents the cascading confusion that follows when the engine tries to render two conflicting story beats at once. Another problem is thread decay. Threads that go unused for more than two sessions lose their priority in the engine and get deprioritized behind newer cues. This is by design, but it means you need to check back on older threads every few sessions or they disappear from the output. I keep a running log of active threads and manually re-anchor the ones that matter before I start a new session. It is a small habit that saves a lot of lost continuity.

What The Tool Does Not Do Well

It does not integrate with any major compendium or bestiary system. You have to build your own cue definitions from scratch. If you are used to importing pre-made content libraries, this tool will feel slow. I have spent time scripting custom parsers to pull data from external sources, and it works, but it is not something a casual user will manage on day one. Performance degrades noticeably when you exceed roughly two hundred active threads. The UI starts to lag, and cue resolution slows from near-instant to several seconds. If you are running a large campaign with many factions and locations, you will hit this wall. The workaround is to archive inactive threads and keep only the active subset loaded. I typically run two projects in parallel: one for current threads and one for archived state, and I merge them back when a previously inactive thread becomes relevant again. There is no undo for cue firing. Once a cue triggers and modifies the narrative state, it is permanent within that session. You can reload the last saved state, but you cannot selectively reverse a single cue outcome. I learned this the hard way when I accidentally triggered a faction escalation cue and spent the rest of the session trying to compensate for a war that started because I misclicked.

Practical Workflow I Use Every Session

I open the project the night before the session and review the current cues and threads. I remove anything that expired or resolved, add any new cues that came up from player discussion, and set the noise seed to a fresh value. Then I close the tool and leave the config file untouched until game time. This prevents accidental saves from sidebar browsing and keeps the runtime state clean. During the session, I have the tool minimized and only bring it up when a player asks about the world or when I need a quick random hook. I do not run it full screen. That habit alone cut my session prep time from about an hour down to roughly twenty minutes, and it kept me from over-managing the background systems instead of actually running the game. After the session, I save the project and take a screenshot of the active thread list before closing. I know it sounds tedious, but having a visual record of the narrative state at the end of each session makes it much faster to pick up where you left off. I have lost state twice by skipping this step, and both times it took an entire evening to reconstruct what happened.

If you are looking for something that handles heavy integration with existing TTRPG ecosystems, this is not it. It is lightweight by design, and that lightness is also its limit. For people who want a simple, passive narrative background manager and are willing to invest time in the initial setup, it works well. I recommend starting with a small project, learning the config structure, and expanding from there rather than trying to migrate a large existing campaign on day one. The tool page is at the standard repository host for this project. It is free, open source, and updated irregularly. The documentation is sparse but the config examples are thorough. I use the default templates and modify them incrementally. That approach has kept my setups stable across multiple versions. One last note. Do not trust the auto-save interval defaults. Set it to manual unless you have a reason to keep it automatic. I switched to manual save three campaigns ago and have not looked back. The extra step of saving at the end of a session takes five seconds and has prevented more data loss issues than I care to count.