Prepare

DQ GM Module Builder

Build and review an adventure you can use again.

Module Builder develops an adventure from a seed into a saved module. It gives story ideas, scenes, NPC roles, and table material a shared structure, so you can check how the pieces fit before taking the adventure to your group.

What it helps you do

Start with a manageable brief

Choose a title, seed, party context, and scope. Preserve established campaign facts as the adventure develops.

Scenes with a purpose

Develop story cards, clues, pressures, choices, and payoffs rather than relying on a long outline alone.

Review and repair

Check contradictions and missing connections, make bounded revisions, and review the result again.

Keep a usable module

Save the adventure to a library with a reader view, cover, summary, and export material.

Prepare visual material

Identify maps and other asset needs, then select and approve candidates for a VTT Studio handoff.

Getting ready

Sign in before starting a build so the finished module can be saved to the intended account. Prepare a title, a story seed, the party’s scope, the setting’s tone, and established facts that the adventure must preserve. These are more useful than a broad request for an exciting story.

Choose a target card count appropriate to the adventure. The main form accepts fifty to one hundred twenty cards, but a larger count does not make scenes more useful. If Mentor-assisted development is enabled, use it to clarify the brief before committing to generation. Browsing the library alone does not start a build.

How to use DQ GM Module Builder

  1. Build from a clear source brief

    Enter the title, seed, and scope, then explicitly start the build. Follow its progress and keep the same account selected while it completes. The build should produce and save a module, rather than leave only a transient preview. If it stops, inspect the reported stage before starting another version.

  2. Read the adventure before adjusting its polish

    Open the saved module and use Reader Mode to understand the premise, conflict, important NPCs, locations, early cards, and night plan. Follow the clue routes and relationships. Check whether a newcomer could understand how the adventure plays without needing the original author to explain every connection.

    Example cover artwork from the module library. A cover gives the adventure a visual identity; Reader Mode and the scene cards provide the material you run.
  3. Check each scene’s playable fields

    Inspect the table prompt, player choice, visible consequence, fail-forward support, clue to reveal, opposition move, and GM deliverable. A readiness mark identifies preparation fields; it does not prove that a clue works. Read the actual text, especially where a failed roll or ignored hook could stop the adventure.

  4. Use review to find specific repairs

    Review contradictions, lost source facts, weak choices, unsupported clues, ignored NPCs, missing props, and climax payoff. Inspect proposed replacements before accepting them. The contextual review allows a bounded repair and recheck rather than an endless rewrite. If problems remain, revise the relevant scene or brief and review again.

  5. Prepare the cast and visual requirements

    Check NPC roles, pressure, and links to scenes, then identify the maps and other assets each scene actually needs. Select and approve candidate material for the VTT Studio packet. A map brief or attractive reference image still needs an editable scene, scale, and asset checks before table use.

  6. Save a useful preparation packet

    Retain the reviewed module, current Reader Mode overview, cover choices, support material, and exports you need. Recheck the overview after changing the adventure so it describes the current cards. Reader Mode can include secrets and opposition instructions; choose separate player handouts rather than sharing the whole GM packet.

  7. Create a Mentor adventure and learn from play

    Use the module-to-Mentor handoff to create the campaign workspace with its cards, nights, and support links. Inspect the opening URL and receipt. This creates an adventure rather than repeatedly overwriting played history. Later Night Review feedback can inform module revisions when it matches the source module and reviewed version.

A game example

Prepare a mystery with more than one route forward

For example, start with a theft, three interested NPCs, and a party that prefers negotiation. Check that the players can discover the key information through more than one route, that each NPC has a reason to act, and that ignoring the first lead has a visible consequence. Add the letter and location brief the GM needs, review the repaired cards, and then create the Mentor adventure. Use later play feedback to improve the reusable module.

What you keep

A saved module

The cards, night assignments, NPC context, source links, and revisions that make up the reusable adventure.

A GM preparation packet

A current overview, early scenes to read, important clues and resources, warnings, and selected support material.

Reviewed handoffs

A Mentor adventure creation receipt and an approved visual-preparation packet for VTT Studio, where used.

How it fits with the other apps

Common questions

What do complete, table-ready, and excellent mean?

They describe different review stages. A structurally complete module may still lack usable scene support. A quality score or AI review can expose issues, but neither establishes that a real group has played and understood the adventure. Inspect the cards and deliverables as GM.

Will rebuilding a module replace my existing Mentor game?

The handoff protects existing adventures. It can return the adventure already created from the same module, while a conflicting name requires another name. Changes to the reusable module do not promise automatic replacement of material in a campaign that has already been played.

Usage guide based on the 7 October 2026 project summary, reviewed 8 October 2026. Examples illustrate possible games. Some connected features require sign-in, GM permissions, or a configured local table.