Virtual tabletops are often compared with feature matrices. One product has dynamic lighting, another has deeper automation, a third supports more modules. The table looks objective and still fails to answer the question that ends campaigns: will this group willingly use it every week?
A better comparison starts with friction. Map the recurring path from preparation to the first meaningful decision, then decide which kinds of inconvenience your group will tolerate.
Write down the session you actually run
Before opening a product page, describe one ordinary session:
- How many people join?
- Are they using laptops, tablets, or a mixture?
- Does anyone have limited bandwidth or an older device?
- Is play mostly maps and precise distance, or conversation and shared notes?
- Who prepares material, and how much time do they have?
- Does the group change game systems often?
- Must campaign data remain under your control?
This turns “best VTT” into a bounded problem. A feature that solves no recurring task is not an advantage. It is another surface to learn and maintain.
Measure the invitation path
Player access is the first test. Count the steps between receiving an invitation and seeing the shared table.
Consider:
- account creation;
- email verification;
- installation or browser requirements;
- downloading campaign assets;
- finding the correct room;
- understanding the first screen;
- configuring audio or another communication tool.
Do not assume a step is free because it happens once. Groups add guests, change computers, clear browser data, and return after long breaks. The host often becomes unpaid technical support at the exact time everyone planned to play.
If two people in your group avoid software setup, choose a tool with a forgiving join flow even if it has less automation. The unused advanced feature has a value of zero.
Price preparation separately from play
Some tools feel effortless to players because the game master performs substantial setup. Others make preparation quick but move more interpretation into the live session.
Track two budgets:
| Budget | Typical tasks |
|---|---|
| Preparation | import maps, build scenes, configure tokens, enter characters, test permissions |
| Live operation | reveal information, move actors, resolve rules, repair mistakes, help players reconnect |
A highly automated ruleset may reduce live arithmetic while increasing preparation and update work. A simple shared canvas may require more conversation but almost no maintenance. Neither is inherently superior.
Choose where you want the effort to live.
Match the spatial model
“Supports maps” covers several different needs.
Position as illustration needs a shared image, rough tokens, and quick annotation. Exact scale may be distracting.
Position as tactics needs reliable grids or measurement, clear layers, and predictable visibility. Small interaction delays become important because every turn uses the map.
Position as exploration needs gradual reveal, persistent notes, and a simple way to move between locations.
No fixed position may need portraits, clocks, cards, handouts, and an excellent shared record instead of a battle map.
Do not buy a tactical map engine for a game that treats distance as conversation. Do not force precise tactical play through a presentation canvas simply because setup is easy.
Treat automation as a dependency
Automation can make a familiar ruleset wonderfully fast. It also creates a stack that can fail: game version, system package, modules, custom sheets, macros, and permissions.
For every automated layer, ask:
- Who understands it well enough to repair it?
- What happens after an update?
- Can the group continue manually when it fails?
- Is the automation transparent enough to trust the result?
The safest automation shortens a frequent operation while leaving the rule visible. A button that rolls, labels, and totals dice is easy to verify. A dense chain of effects that silently modifies several actors may be powerful but hard to audit during play.
Decide what ownership means
Campaign data may live in a hosted account, a local application, a self-hosted server, exported files, or some mixture. “Ownership” is not just a philosophical preference. It affects backups, migration, guest access, and the cost of leaving.
Check whether you can export:
- character records;
- maps and uploaded media;
- notes and handouts;
- chat or session logs when those matter;
- campaign configuration in a documented format.
An export that only the same product can read is a backup, not a migration path. If a long campaign matters, perform one test export before committing months of work.
Run a twenty-minute pilot
Do not test by building the perfect campaign. Recreate one ordinary encounter or scene.
- Invite a player using the least convenient device in the group.
- Load one map or handout.
- Complete the most common action three times.
- Make and undo a mistake.
- Reconnect after closing the client.
- Export or back up the result.
Write down every moment where someone had to leave the shared context to search documentation. Those interruptions are more predictive than the product’s longest feature list.
Use a friction ledger
Score only the things your session repeats:
| Question | Weight | Candidate A | Candidate B |
|---|---|---|---|
| Can everyone join without help? | 5 | ||
| Can the host prepare an ordinary session quickly? | 4 | ||
| Does the spatial model fit the game? | 5 | ||
| Can common actions be corrected easily? | 3 | ||
| Can campaign data be backed up or moved? | 4 | ||
| Are updates and dependencies understandable? | 3 |
Add advanced features only after the recurring path works. Your group may rationally choose the less capable tool because it disappears faster once play begins.
That is not settling. A play tool succeeds when attention moves away from the tool and back to the table.