Windrose Multiple Worlds and Crew Switching Guide

Windrose Multiple Worlds and Crew Switching

One of the first things hosted Windrose crews discover is that a single server is often not enough for every use case. A tight four-person progression group may want one persistent world. A broader community may want a separate testing or casual world. Friends returning at different times may want to preserve one serious campaign while keeping another sandbox for relaxed play. The dedicated-server guide proves that Windrose is not a disposable session game anymore; it is a persistent-world game with real save value. That makes multi-world administration important. The trick is to treat each Windrose world as its own identity, not just as a folder you swap casually. In practical terms, that means keeping world-specific save data, metadata, and recovery notes together. If you try to run multiple crews by loosely copying files in and out without structure, you eventually create confusion: wrong world loaded, invite code changed unexpectedly, or a restore that brought back the wrong campaign. A proper Windrose multi-world setup is not complex, but it does need discipline.

What counts as a "world bundle" in Windrose

Why casual file swapping causes problems

Many admins reach for the simplest idea first: stop the server, copy a different save folder into place, start the server again, and call that "world switching." Sometimes that works. Sometimes it produces a confusing half-state where the world data came from one campaign but the metadata still points at another identity. In Windrose, that is risky because the join model is code-based and the metadata files are meaningful. If you want reliable multi-world administration, you need to switch whole bundles, not just whichever folder seems important at the time.

That means a proper world switch should always answer three questions:

1. Which crew or campaign is supposed to go live?
2. Which save data belongs to that campaign?
3. Which metadata files belong with that save?

If you cannot answer those quickly, you are not ready to switch.

Best structure for separate crews

The cleanest operating model is to keep each campaign in its own labeled archive or staging directory. For example:

windrose-worlds/
  crew-alpha-main/
    ServerDescription.json
    WorldDescription.json
    SaveProfiles/
    notes.txt
  crew-bravo-casual/
    ServerDescription.json
    WorldDescription.json
    SaveProfiles/
    notes.txt
  officers-test-world/
    ...

This makes your job dramatically easier. Instead of asking "Which files were the right ones last week?" you ask "Which world bundle are we activating tonight?" That is an operationally sane question. The first one is how mistakes happen.

How to switch worlds safely

1. Announce downtime so nobody is actively playing.
2. Stop the Windrose server cleanly.
3. Back up the currently active world before changing anything.
4. Archive the active world's metadata and save data as one labeled bundle.
5. Copy the target world's metadata and save bundle into the live server path.
6. Start the server and let it finish initialization.
7. Verify the invite code and test the world with one client.
8. Only then publish the new invite code to the intended crew.

This process is slower than reckless file swapping, but not by much. And it is far safer.

Should you run separate server roots instead of switching bundles?

In some setups, yes. If you know you will frequently alternate between worlds, keeping distinct server roots can be cleaner than constantly replacing files in one live directory. Separate roots reduce the chance of accidental overlap and make audit trails simpler. The downside is more storage use and slightly more operational complexity. The upside is clear separation. For hosts managing multiple serious Windrose crews, separate roots are often worth it. For a smaller setup where a single group occasionally swaps between "main world" and "test world," a single root with disciplined bundle restores may be enough.

The key is consistency. Pick one model and operate it cleanly. Hybrid chaos is what hurts.

How to avoid save collisions

A save collision is any situation where one crew's world data, metadata, or live changes overwrite another crew's state. In Windrose, collisions usually come from one of three habits:

• Running two campaigns through one poorly labeled live directory
• Restoring only part of a world's bundle
• Letting players back in before verifying the intended world is active

All three are preventable. Label everything. Restore complete bundles. Validate before reopening. That is the whole playbook.

How to manage different world purposes

Most Windrose hosts do not need endless worlds. They need a few distinct roles:

• Main progression world: the serious campaign your crew cares about most
• Testing world: a low-risk place for experimentation after patches or config edits
• Casual or guest world: a lower-stakes world for less consistent players

That structure helps because it aligns technical decisions with social expectations. The main progression world gets the most conservative backups and the strictest update discipline. The testing world absorbs experiments first. The casual world can tolerate more churn.

Why invite-code communication matters when switching crews

Windrose is not a static address game right now. Invite-code based access means world switching is also a communication exercise. If you change campaigns and publish the new code badly, players may think the server is broken when they are simply using the wrong token for the wrong world. A reliable host should tell players three things after every switch:

1. Which world is now active
2. Who it is intended for
3. What the new invite code is

This sounds obvious, but it prevents a lot of messy support conversations.

How to recover if the wrong world went live

If you accidentally boot the wrong campaign, fix it quickly and methodically. Stop the server. Archive the mistaken live state so you do not lose any surprise changes. Restore the intended world bundle. Start the server again and verify the code. The worst response is panic-editing files while the process is still running or trying to "just switch one JSON back." Once you suspect a world identity mistake, go back to the full bundle model and restore cleanly.

Multiple crews means multiple backup policies

Do not use the same retention logic for every Windrose world. Your main world may deserve longer retention and more frequent backups because the social cost of losing it is high. A testing world may only need short-term snapshots. By separating world roles, you also make backup economics sane. Not every world deserves infinite retention, but every important world deserves a clear policy.

Suggested admin naming standard

That gives you names like crew-alpha_main_2026-04-15_2100_pre-hotfix. It is not pretty. It is useful. That is what matters.

Sources

• Official Windrose Dedicated Server Guide
• Windrose Steam store page