A fantasy map maker becomes a different kind of tool when several people contribute to the same world. One person sees an abandoned bridge and invents a rebellion. Another sees the same bridge as the only safe route to a market. A third wants to remove it because the river should divide two cultures. Each idea can be useful, yet a map filled with every suggestion can become harder to understand. Collaborative worldbuilding works best when the group agrees on how ideas become decisions, how decisions reach the map, and which version everyone is discussing.
This workflow uses a fictional region called the Bellwater Reach. Three collaborators are preparing a short campaign: Mara plans settlements, Oren develops journeys, and Sel writes the region's history. The example explains how to organize their contributions using a generated map, a written decision record, and saved files. The website does not offer simultaneous editing accounts or a shared online workspace. Collaboration happens through the files, images, links, and communication tools the group chooses to use.
Agree on the map's immediate purpose
Before generating geography, finish one practical sentence together: this map will help us do what? Bellwater's group chooses “prepare six sessions of travel between a river town and an abandoned observatory.” That purpose is more useful than “create an impressive world.” It sets a scale, limits the number of places needing detail, and gives the group a reason to reject attractive ideas that belong in a later project. An entire continent can remain a background possibility while the current map supports a manageable journey.
Each contributor then identifies one outcome they need. Mara needs settlement names that are easy to remember. Oren needs two plausible paths with different difficulties. Sel needs one historical event that explains why the observatory was abandoned. These needs overlap without being identical. Write them beside the project brief so geography can be judged against actual use. A mountain range that blocks both routes may create a striking composition while preventing the scenario the group agreed to prepare.
Use the map planning guide for novels when the shared project is a story rather than a campaign. Its distinction between necessary geography and decorative background also helps teams. Contributors can imagine more than the finished map displays. The purpose statement identifies which parts require a decision now, while the rest can remain ideas in a separate notebook.
Choose one baseline before adding details
Create a small selection of maps using the same broad map type. Compare them together against the purpose statement, then choose one baseline. Do not give each collaborator a different seed and ask them to develop the same region independently unless the task is explicitly an exploration of alternatives. Different coastlines make subsequent arguments about roads and settlements difficult to resolve because the participants are no longer referring to the same physical setting.
Bellwater's group selects a continent style map with a prominent river corridor and nearby hills. The exact generated names are provisional. The group saves the editable file and a PNG preview, then records the seed and generation settings in its notes. The seed helps identify the starting geography under the current implementation, but the editable file is needed to preserve supported manual changes. A screenshot alone cannot restore those changes in the generator.
Start with the world map generator or another suitable map type, and follow the seed guide if the difference between repeatable settings and a saved edited project is unclear. A baseline is a shared reference, not an agreement to keep every generated detail. Renaming a town is a small decision; replacing the whole map later changes the foundation of everyone else's work.
Assign decisions instead of dividing every square
Dividing a map into three equal territories seems fair, but rivers, trade, and journeys cross those territories. Contributors may independently create incompatible explanations for the same frontier. A more practical arrangement assigns areas of responsibility: settlement clarity, route continuity, historical consistency, and final editing. These responsibilities can rotate. They identify who gathers proposals and checks a decision, rather than giving someone permanent ownership of part of the imaginary world.
Mara gathers place name proposals and checks repeated names. Oren reviews whether the planned journey still works when a new obstacle is added. Sel checks whether a proposed ruin contradicts the agreed history. One person applies approved changes to the editable map during each review. This avoids competing master files while preserving everyone's creative input. The editor is carrying out decisions, not acquiring extra authority over the fiction.
Record decisions that need a group discussion separately from changes an editor can make immediately. Correcting a spelling inconsistency may not require another meeting. Moving the campaign's starting settlement to the opposite side of a mountain range probably does. Agree on that distinction in advance so contributors do not experience every small correction as a veto or every large change as an unexpected fait accompli.
Make proposals that others can evaluate
A useful proposal includes a location, a reason, and a consequence. “Add a fortress” gives the group little to assess. “Add a ruined watchtower above the eastern ferry so travelers can observe both banks, creating an optional investigation before the crossing” connects geography to the shared purpose. The group can decide whether that consequence improves the journey, duplicates another scene, or creates work beyond the present project.
Use approximate written locations when exact map editing is unavailable. “North of Bellwater, beside the narrow river bend” is clearer than “over there” and remains understandable in a text conversation. If a location must be precise, mark a copy of the preview in an external annotation tool and label the proposal. Do not imply that the generator provides a shared comment layer. The annotation is a reference for the editor, and the original preview should remain available for comparison.
Include a cost when the proposal changes existing work. Sel's proposed watchtower requires one paragraph of history and a new name. Moving the river town requires revising three journeys and the campaign opening. Both ideas may be good, but their consequences differ. Naming the revision cost lets the group weigh the idea fairly rather than discovering its effect only after someone has already edited the map.
Separate approved facts, possibilities, and secrets
Keep three distinct lists in the project notes: approved facts, unapproved possibilities, and information restricted to particular readers. This separation does not need elaborate software. A short document with clear headings works. The map should display the facts required by its audience; proposals can remain in the possibilities list until the group decides what they mean. A rumor can exist as a rumor without becoming an objective historical event.
Bellwater's approved facts state that the ferry operates near the market town and the observatory has been closed for twenty years. A possible idea says that a hidden stair connects the observatory to a cave. The game master's secret notes may explain who knows about that stair. Adding the secret entrance to a shared preview would reveal information even if its label were later removed. Decide which edition a file represents before distributing it.
The player and game master map guide describes audience differences in more detail. Collaboration does not require giving every contributor every secret, but restricted information should not make the public geography incoherent. The visible route still needs a sensible explanation even when its hidden danger remains in a private document.
Resolve conflicting ideas through the agreed purpose
When ideas conflict, begin with the shared purpose rather than deciding whose imagination is better. Mara wants the watchtower occupied because that supports a lively settlement. Sel wants it abandoned because that supports the observatory's history. Oren needs a place where travelers can rest. The group can preserve the abandoned structure and place a small seasonal camp beside it. This solution meets several needs without requiring every proposal to survive unchanged.
Some conflicts need a direct choice. If one route requires an impassable mountain wall and another requires a broad road through that same location, the group should select an explanation that supports the planned journey. A named pass might resolve the contradiction, but only if the group wants its consequences. Adding exceptions to every obstacle can erase the distinctiveness of the geography. Decide what travelers can do, why, and under what conditions.
Write a one sentence explanation after a significant decision. “The tower remains abandoned, while ferry guards camp below it during market weeks” is enough. A contributor returning after an absence can understand what changed without reconstructing a long chat. This record also prevents a rejected idea from returning as an apparently new proposal simply because the earlier discussion was difficult to find.
Apply approved changes in controlled batches
Group changes into a manageable editing batch. Start with approved names, then supported landmarks, then presentation adjustments. Keep a saved file from before the batch. Changes to generated labels affect their text and presentation; dragging their text does not relocate underlying city markers or terrain. If a proposed settlement requires geography the tool cannot move, record it in the notes or prepare a later edition in an appropriate external editor.
After editing, export a new preview and compare it with the decision record. Check the names, intended audience, and relationship between labels and locations. A beautifully styled map can still apply the wrong proposal. Ask another collaborator to perform this review because the person who made the changes may read what they expected to enter instead of what is actually displayed.
For placement capabilities and their limits, consult the landmark editing guide. The distinction between changing an existing name and adding a supported extra symbol matters particularly in teams. A proposal should describe its intended result, while the editor should explain any limitation that affects how faithfully the tool can represent it.
Share a version with a clear status
Give each reviewed release a short version name, such as Bellwater draft 03 or Bellwater player edition 01. Include that version in filenames and the review message. Keep the editable JSON, image export, and decision notes together. A share link is useful for handing over supported settings and edits, but anyone receiving the complete link may inspect the embedded information. It is not an invitation system with collaborator permissions.
State whether recipients should comment, approve, or use the edition. “Please check place names by Friday” asks for a different action than “This is the map for the next session.” Without a status, people may continue proposing structural changes after an edition has already been printed. A deadline can close a review round without declaring the world permanently finished.
Use the share link guide and editable file guide for handover details. Test the shared result yourself before distributing it widely. A link copied from an old tab, a file with an unclear name, or a preview from an earlier batch can make a careful collaboration appear inconsistent.
A complete Bellwater review round
The first Bellwater round begins with three proposals: rename the market town, add the ruined tower, and show a second route through the hills. Mara collects two name options and the group selects Bellwater because it is short and distinct from neighboring labels. Sel writes the tower's agreed history in four sentences. Oren describes the hill route in the notebook because the generator does not provide a freehand route drawing tool. The editor renames the town and adds a supported landmark where the group intended the tower.
The reviewer spots that the landmark label covers the ferry name. The editor moves the text slightly, checks that the tower's intended location remains clear, and exports again. The group approves the revised image while keeping the route explanation in the accompanying notes. This is a successful review even though the map does not contain every sentence of the worldbuilding. The visual artifact and written material have complementary jobs.
At the next session, players decide to avoid the ferry. The group adds this outcome to the notes and considers whether the next public edition needs an update. They do not silently alter the previously distributed file. Keeping the older version explains what players saw when they made their decision. Collaboration becomes easier when the group can distinguish changing fiction from a mistaken record of earlier fiction.
Finish the round without ending the world
A collaborative map is ready when the intended audience can use it, approved decisions are represented accurately, and the next editor can identify the current file. It does not need to exhaust everyone's ideas. Put unused proposals into a future list, assign a next review only if needed, and preserve the approved release. A small shared map with a reliable history is more useful than an enormous map whose collaborators cannot agree which version is current.
Continue with the worldbuilding notebook workflow to organize the notes behind the image. Then return to the fantasy map maker with a clear editing batch. The map can keep growing as the project develops, while each released edition remains understandable to the people who rely on it.

Give the idea a world of its own.
Try the technique in the generator, then save an editable copy so you can return to your work.
Open the map maker ↗