APLobbyGen

A local-first front end for running Archipelago multiworlds on Windows. The roster lives on your machine, generation never touches the network, and the seed can be hosted right here.

View on GitHub Download Licence

The APLobbyGen window: a lobby of eleven players, each row showing the game, the world file that resolves it, its version and its status. — Every player resolved against the world files actually installed. ready, world must match (the apworld ships a client, so every player needs the identical file), sitting out, and no world installed — which is why Generate is off, and it says so rather than just greying out. Players shown are invented.

The APLobbyGen window in dark mode: a lobby of eleven players, each row showing the game, the world file that resolves it, its version and its status. — Every player resolved against the world files actually installed. ready, world must match (the apworld ships a client, so every player needs the identical file), sitting out, and no world installed — which is why Generate is off, and it says so rather than just greying out. Players shown are invented.

Why it exists

Most tooling around a multiworld treats a remote lobby as the source of truth. Every generation re-scrapes someone else's server, the roster evaporates between runs, and nothing works offline. Here the local lobby owns the roster; a remote room is one way to put configs into it, not the thing that defines it.

Standard library only — no pip install, no virtualenv. If you have Python and an Archipelago install, you have everything.

What it does

A roster that survives Configs live in a local lobby with a manifest, retained history for superseded versions, and per-player include / sit-out. Re-importing an unchanged config is a no-op; a changed one updates in place and keeps the previous version.
Import from anywhere A lobby room, a folder, a zip, or individual .yaml files. The remote room is one importer among several rather than the foundation.
Preflight that tells you the truth Every player's game is resolved against the .apworld files actually installed, so a missing world is something you learn before generating, not after.
Dropped settings are a failure, not a footnote When a config asks for an option the installed world does not have, Archipelago drops it silently and produces a seed that looks fine while a player quietly does not get the game they configured. That exits non-zero here unless you waive it.
A lock beside every seed Each run records what it was built from — world files, hashes, versions, sources — so a seed stays explicable months later.
Where to get things Two upstreams matter per game and they are different questions: the .apworld the generator needs, and the client or mod the player installs to actually play. Both are tracked as links, with the evidence each claim was read from, and the games in your lobby are checked first.
Host it locally Start the Archipelago server on this machine against the seed you just made, with the server console right there. Publishing to archipelago.gg stays a separate, deliberate step.

Getting started

Windows, Python 3.10 or newer with tkinter, and an Archipelago install.

git clone https://github.com/vitsorg/APLobbyGen
cd APLobbyGen
python aplobby_gui.py

Or from the command line

python aplobby.py import folder path\to\configs   add configs to the lobby
python aplobby.py list                            show the roster
python aplobby.py generate                        build a seed, no network
python aplobby.py host                            host it on this machine

Nothing is downloaded for you. The tool tells you which world file and which client each game needs, and links to them. GitHub release layouts differ enough per project that guessing which asset to fetch would do more harm than a person clicking through. World files and player configs are self-supplied.

Verification

Five test suites, all offline except the one that deliberately hosts on loopback and connects to itself. They assert rather than print, so a silent pass is a real pass — including one that drives the real window with nobody watching.

python selftest_lobby.py     the store: identity, history, crash recovery
python selftest_sources.py   the importers, with the network stubbed
python selftest_gui.py       drives the real window with nobody watching
python selftest_serve.py     really starts a server, really connects to it
python selftest_links.py     the upstream pointers and their client states

Licence and contributing

Source-available rather than open source: run it freely for Archipelago multiworlds and share it unmodified, but changes come back here as pull requests instead of being published as a separate version. Forking to open a PR is explicitly permitted. See the licence for the exact terms.