Build a Low-Bandwidth VTT Setup That Fails Gracefully

A low-bandwidth virtual tabletop is not a fully loaded VTT with every slider turned down. It is a session architecture with a known failure path. When a map stalls, lighting breaks, or one player’s connection deteriorates, the group should know what disappears first and what must remain for play to continue.

The design target is simple: preserve communication, shared state, and the next meaningful decision. Everything else is optional until proven reliable on the least capable connection and device at the table.

Diagnose the constraint before changing tools

“The VTT is slow” can describe at least three different failures:

Constraint	Typical symptom	First thing to inspect
Network transfer	slow initial load, missing assets, delayed updates	asset size, host upload path, connection stability
Local rendering	choppy pans, delayed token movement, lighting glitches	scene complexity, browser acceleration, effects
Communication	broken audio, frozen video, repeated reconnects	video load, call service, competing traffic

Roll20’s official system guidance separates network speed from the computer’s ability to render graphics. Its lighting documentation also notes that dynamic lighting uses WebGL and can tax lower-performing machines. That distinction matters: compressing a map may help a slow download but will not repair an unsupported graphics path; moving hosting to the cloud may improve the server connection but will not make an old client render a complex scene smoothly.

Ask the affected player what fails and when. “The first map takes four minutes to appear” leads to a different remedy than “everything loads, but moving a token stutters.”

Define the minimum viable table

Write down what the session needs after every enhancement is removed. For many games, the minimum is:

1. a stable voice channel or usable text channel;
2. a shared statement of the current situation;
3. character information each player can access;
4. a trusted way to resolve uncertain outcomes;
5. a record of important state changes.

A map is only mandatory when position itself drives decisions. Integrated sheets are only mandatory when the group cannot resolve the rules without them. Built-in audio is only mandatory if there is no independent communication path.

This is not an argument for playing without useful tools. It is a test of whether the session has a core that survives their loss.

Build a degradation ladder before the session

Arrange features from essential to expendable. Here is a system-neutral starting point:

Level	What remains	What can be removed
0. Conversation	voice or text, current situation, decisions	every visual and automated layer
1. Shared state	one static map or scene image, basic markers, short notes	animation, lighting, decorative props
2. Play aids	character sheets, dice log, essential handouts	nonessential automation and media
3. Automation	rules helpers, macros, measured movement	complex effects and ambient media
4. Presentation	lighting, animation, music, layered decoration	nothing; this is the full setup

The numbering describes dependency, not quality. Level 0 is the last line of continuity. Level 4 is allowed only when every lower level already works.

Give each transition a concrete action. “If two people report delayed updates, disable animated media” is actionable. “Use fewer features if it gets laggy” forces the group to diagnose the system in the middle of play.

Give the first scene an asset budget

Players cannot make the first decision until the assets needed for it arrive and render. Treat the opening scene as a separate delivery package.

• Export maps for screen use rather than pulling print-resolution images directly from a PDF.
• Crop away areas no player can see during the session.
• Prefer one static background over several full-canvas decorative layers.
• Use transparent files where transparency matters, not by default for every large image.
• Keep animated backgrounds, weather, and ambient loops out of the critical path.
• Open the actual player view on a clean browser profile before the session.

Roll20’s file guidance explicitly warns that print-oriented assets can be larger than a game needs and that large animations may take additional time to reach players on weak connections. Foundry’s hosting guide similarly notes that internet speed becomes a limiting factor for self-hosted worlds with substantial multimedia content.

There is no universal “safe” file size. A useful budget is empirical: the complete first decision should become available on the group’s weakest real device and connection within a wait the group accepts.

Separate communication from presentation

Video is socially useful, but it should not share the same priority as intelligible speech. Roll20’s network documentation identifies voice and video as particularly sensitive to connection quality and suggests that a dedicated communication service may be worth considering when integrated chat remains unreliable.

Choose the fallback before play:

• cameras off, audio remains;
• one active speaker on video, if the call tool supports that workflow;
• audio moves to a familiar dedicated service;
• text becomes the emergency channel for short decisions and state changes.

Do not discover everyone’s account, invite, and device requirements at the moment the main call fails. A fallback that nobody has joined is only a second untested system.

Let hosting solve the problem it can solve

In a self-hosted Foundry session, remote players connect to the host’s machine. Foundry’s official guide warns that the host’s internet connection can become the limiting factor, particularly when a world contains a lot of multimedia. Cloud or partner hosting moves that server-side path to a datacenter connection.

That can be a meaningful change, but it is not a universal performance upgrade. The player still downloads assets and renders the scene. If only one old laptop struggles while everyone else is comfortable, reducing that player’s render load may be more relevant than moving the server.

This is the same principle as choosing a VTT by friction: locate the recurring cost before buying a broader solution.

Layer images according to their job

Owlbear Rodeo’s image model distinguishes maps, props, characters, attachments, and notes. Even if your chosen VTT uses different names, the separation is useful.

Ask what each visual layer changes:

• map: establishes navigable space;
• marker: changes position or ownership;
• prop: introduces an interactive object;
• status: changes what is true about a character;
• note: preserves information players need to consult.

If a layer changes none of those things, it is presentation. Keep it outside the minimum viable scene. This makes graceful degradation legible: removing fog animation should not also remove the only marker showing which bridge has collapsed.

Rehearse one controlled failure

A useful pre-session test takes about fifteen minutes:

1. Join through the least capable device the group expects to use.
2. Start from a fresh private window so cached assets do not hide the initial load.
3. Open the first scene and complete one ordinary action.
4. Disable video and remove presentation-level media.
5. Confirm that everyone can still identify the situation and act.
6. Close the VTT entirely and continue for two minutes through the Level 0 fallback.
7. Record the exact link, file, or message needed to restore shared state.

The objective is not to simulate every outage. It is to prove that the group can cross one boundary without losing the thread of play.

Use a fixed drop order during play

When trouble begins, remove load in a predictable order:

1. cameras;
2. ambient audio and animated media;
3. dynamic lighting and decorative layers;
4. nonessential automation;
5. the live VTT itself, replaced by a static image and shared notes;
6. visuals, leaving voice or text plus a concise state summary.

Pause after each step long enough to see whether the symptom changes. Dropping everything at once may restore the session, but it teaches nothing about the actual constraint.

A graceful setup does not promise that technology will never fail. It makes failure smaller than the session. The group may lose spectacle, automation, or spatial precision, but it does not lose the decision currently on the table.