A warmup path through the playtest

This first run is best for a table that already knows the rhythm of PF2e, or something close to it, and does not mind a little “let’s get everyone settled in” time at the top. The GM is trying a new prep flow, so part of the first call is making sure characters, maps, handouts, exports, and combat all land where they should. If you already use Owlbear and Wanderer’s Guide, most of this will feel familiar. The new WG combat view is a little different, but it should feel comfortable once someone walks through a round.

Plan on about 45–60 minutes for the warmup. Not every player has to make it. If a few people can attend, that is enough to shake out the tool flow and help the rest of the table later. There is also a short video walkthrough, so nobody needs to learn everything live. The main goal is to make the first real adventure session feel easy.

Map it to a table you already run: Wanderer’s Guide is Pathbuilder (build the PC, share a public sheet link, or export JSON if the character stays private). The new WG UI in combat is the live sheet and tracker—what you click in Foundry’s character sheet / combat tracker, not the map. AMBA is the GM’s module notes (the PDF, the Foundry journal, the stuff players never edit). Owlbear is the battle map only (Foundry canvas, Roll20 scene). Discord is still voice. In AMBA the GM builds a module or adventure; after export that is a campaign in WG—same table, two names. Old and new WG UI share one stack, so a join key works in either builder; combat on the call is new UI only.

Warmup session

Most of the warmup is just getting comfortable: open the player link, check WG characters, connect Owlbear, make sure tokens and sheets show up, build one tiny encounter, export it, run one round in the new WG combat view, and try one challenge screen. If we get through some or all of that, great. Anyone who attends can help answer quick questions for folks who catch up from the video.

1. Bring a couple of characters

Before the call, sign in on AMBA’s WG clone and make any characters you want considered. Build in old UI or new UI if you want to compare them—same job as Pathbuilder, two apps on one stack. The smoothest path is to turn on Public Character and save the public sheet link on the WG page. If a character is staying private, export WG JSON and use Uploads instead. Combat on the call uses new UI only.

2. Gather in Discord

Everyone joins the same voice channel. Open the Discord page for the server widget, text channel, and voice toggle. When we first meet, we will pick a fun party from the characters on Signup and any private-character uploads. No need to open every tool at once. We will bring each one in as it becomes useful.

3. Start with a tiny AMBA shell

The GM screen-shares AMBA, signs in, and creates a blank module or adventure first—a small named container with nothing in it yet. Once that exists, the GM imports public characters from their WG links, or uses uploaded JSON for any private characters. This is just the setup pass, not the full adventure build. Link WG later if the export step needs it.

4. Let Owlbear meet the party

Switch to Owlbear. The GM screen-shares, loads the AMBA-related extensions, connects that room to the stub module, and runs import PCs and character sheets. Players join the room, take ownership of their own token, and move around a bit so we know the table pieces are awake.

5. Build the first playable bit

Screen-share AMBA again. Together, make the first act, then a scene, then an encounter. This does not need to be polished prep. We are mostly seeing how the pieces feel when we build at table speed. Optional: players who want to follow along can use an AMBA account plus module sharing (Shared, not their own copy). Screen-share still works if they skip that.

6. Share the player packet

Players do not log into AMBA. They get a player-only syndication link for the module or adventure—read-only HTML, no account. In AMBA Settings, under Player version, create the player version, then Copy player link into Discord. Open Manage publish tree and leave only the initial nodes checked (overview, gazetteer, no-spoiler handouts, Act 1 intro—not later scenes, GM packets, or spoilers). Players bookmark that URL. As the table hits later scenes, the GM returns to the publish tree, checks the newly reached nodes, saves, and players refresh the bookmark. Think of it as a living handout packet: unchecked nodes stay GM-only.

7. Add a map and some trouble

On Discord, pick a quick map with Watabou. Then in AMBA make one tiny monster encounter or simple threat. With a map and creature in place, the GM exports to both WG and Owlbear. After that export, share the WG join key in Discord if players need to join the campaign in the new WGUI. Never share the API key. If the new map or encounter should be on the player packet, check those nodes on the publish tree and save; players refresh the syndication bookmark.

8. Try a short combat

Together we run one round in the new WGUI combat view. Export the encounter to WG and import it from Owlbear. PCs leave the Party bench and join the encounter. Every enemy and ally should be represented. Combat starts with initiative in the new WGUI tracker. Talk out loud about what feels natural, what takes hunting, and what makes the table faster. Reveal the combat map or aftermath nodes on the player publish tree if those belong on the packet.

9. Try a challenge moment

If time allows, use the new skill-check challenge screens with one trap, hazard, or social beat. Run it on the call so we can see whether the challenge flow feels comfortable in play. Publish player-safe challenge or handout nodes after they resolve; leave GM notes and unreached scenes unchecked.

10. Capture the useful bits

Drop notes on feedback whenever something clicks, stalls, surprises you, or makes you laugh. Notes during the call are perfect. We are not grading the session; we are collecting the parts that help the next one feel smoother.