Section 1 of 7
What this is
Getting a working modded game takes many steps and fails often. You find content that works together, work out its dependencies and the game version it wants, download, install, configure, then repair whatever broke. A setup that goes wrong often gets abandoned. Curators carry the blame for it through success ratings that measure something they don't control. Support channels carry the rest.
Collections Launcher turns a prepared list of mods and a game you own on Steam into a playable modded game from a single action.
You choose a game, choose a collection, and press Play. Nothing else is asked of you after that. The launcher provisions the game from your Steam account at a specific build, resolves the mod list to an exact set of files, installs them, and starts the game. Choose another collection, press Play again, and that one runs too. Neither disturbs the other.
Read this first
A demonstrator exists to make an argument concrete: show that a mod list can install the same way every time when the environment underneath it is known. It shows nothing about whether players want to work this way. It commits us to nothing.
Research at Nexus Mods is a category of work with a question, a timebox and an owner. It ends with one of four outcomes: decide, run a further experiment, defer, or close with no action. Closing with no action counts as a success when it kills a bad assumption. Read everything below as evidence for a decision, not as an announcement.
Section 2 of 7
In this release
What the demonstrator does today. Every item here is something you can watch happen.
One action, start to finish
Choosing a collection and pressing Play is the last input. Provisioning, resolution, installation and launch run unattended from there. No prompt, no folder to pick, no step that needs a guide.
A specific game version
The launcher asks Steam for the exact build a collection was made against, rather than whatever is current. A game update then leaves that collection alone. The recent Skyrim update is an example of the breakage a pinned build could avoid.
A clean instance, from nothing
The run starts on a machine that has never had the game installed. There is no existing folder to inspect, repair or work around, so nothing left over from a previous setup can change the result.
Several revisions side by side
You can install more than one revision of the same collection. Each is isolated, so a run of one cannot change what another sees. Files the revisions share are stored once, not copied per revision.
The game comes from Steam
The launcher signs in to your Steam account and retrieves the game files that account owns. It is your licence and your copy. Nothing about the game is redistributed.
One extraction path
Everything installs the same way.
Windows, Steam, a handful of games
Several games are supported, all of them through one store on one platform. Running on Linux and Mac were both stretch goals and are not in this release, but are feasible.
Section 3 of 7
What we want from you
Everyone seeing this now is inside the company. We want your reaction to the demonstrator rather than a verdict on it. The last section describes the decision it feeds into.
Where to get it
collections-launcher.exe
- Watch a run from start to finish, or run one yourself. The Slack announcement has videos of full runs.
- Say whether what you saw looks like a good direction for curated modding, and why. A reasoned no is worth as much as a yes.
- Bring an objection that the list below misses. Every objection there came from someone, so a missing one is the useful kind of gap.
- If you can answer one of the open questions at the end, or you already own the area it touches, say so.
Laser Sharks run this research. Send it to them in #team-lazer-sharks, or to #tech-ugc-platform-rnd directly.
Keep the build and the runs inside the company for now.
The project, the PRD and the evidence behind it are in Linear. The research process that governs how this ends is in Notion. Both are internal.
Section 4 of 7
What made it possible
Some of this launcher is assembly. The heaviest piece underneath it is platform work built to make demonstrators like this one possible. That work is the repacking of mod archives.
A mod typically arrives as an archive: a bundle of files squashed down into one file for download.
Authors upload whatever format they prefer, usually 7-Zip, RAR or ZIP.
We repack to a ZIP you can jump around inside, so pulling one file out no longer costs the whole bundle.
The launcher can then take one file out of an archive without downloading or unpacking the rest of it, and every mod installs the same way whatever format its author uploaded.
Hashes and manifests on every file
Every new upload is fingerprinted and comes with a list of what is inside it. The fingerprint identifies a mod by its contents rather than by its filename, which is what lets the launcher ask for one exact file and know that the file it received is that one.
Resolution done ahead of time
A collection is worked out into an exact set of files before you press Play, not while you wait. The launcher looks up an answer that has already been decided instead of searching for one.
A virtual file system
The game is shown mod files in the places it expects to find them, without a full copy of every mod having to be written to disk for each collection. A mod is stored once and pointed at from every collection that uses it.
ℹ️
Shared, not copied
Collections for the same game overlap heavily, so the saving grows with every one you install. Where two Skyrim collections share four fifths of their mod list, installing the first leaves the second most of the way to playable before it downloads anything, and those shared mods cost disk once.
Section 5 of 7
Most obvious objections
Grouped by who tends to raise them.
For modders
"Repacking turns my files into your files."
Repacking changes the container, not the contents. The files inside are byte-for-byte what the author uploaded. The original upload stays the default download and is never replaced, because breaking that would break every tool and workflow built on it. A repack is something the platform holds in addition.
"I do not want another copy of the game on my disk."
Collections don't each get their own copy. However many you install through the launcher, the game is provisioned once and shared between them.
The exception is a game you already have installed through another launcher. That install stays where it is, so for now you would have two copies. Reusing one the launcher didn't create is a gap in the demonstrator rather than a property of the approach.
"One click means no tinkering."
The launcher installs a list somebody else curated, for someone who wants to play it. It removes nothing. Manual modding, and every existing way of doing it, carries on exactly as before.
"Pinning the game version leaves me on an old build."
Pinning is what makes the collection work at all. A collection is built against a particular game build, and a game update is the usual reason one stops working. Installing the build it was made for is the repair. Your other installs, pinned or not, are unaffected.
For engineers
"This is instances and profiles. Wabbajack and MO2 have done it for years."
Agreed on the model, and that is the point: the reliable shape is already known. What is different is where the work happens. Resolution runs against published per-file data instead of a list assembled by hand. The game comes from the store at a named build, not from whatever happens to be on disk.
"A seekable ZIP is a bet on tool support."
It is a small one. Both candidates stay inside the ZIP container. The original upload is always what a download gives you, so we are betting on a reprocessing run, not on tool support.
"A hand-prepared whitelist flatters the approach."
It does. A curated set prepared by people who know the system hides the per-mod authoring cost. That cost decides whether any of this scales. The whitelist deliberately includes hard cases: large lists, mods that need a specific game build.
"Prototype code has a habit of shipping."
Prototypes here are throwaway by doctrine, including the AI-assisted ones. Production standards apply only when work graduates to a delivery initiative. Any follow-on build starts with its own PRD.
"Datamining mods for compatibility data will not scale."
Open. Earlier research showed the data can be captured. How much of it is needed to express what a mod requires is unanswered. Answering that is the next piece of research, not something this release settles.
For the business
"Is this a commitment to ship?"
No. It exists to inform one technical decision: whether clean provisioning, end-to-end version pinning and manifest-driven resolution become the target approach for deterministic installs. A second decision follows from it, about who outside the company sees this and on what terms.
"This looks expensive."
The launcher itself is small. The heavy pieces underneath it are the platform work in What made it possible, which already exists. Retrieving games from stores and resolving a mod list were built here, and neither was large. The cost that decides this is preparing the per-collection data. That number is not yet known.
"Why build something new instead of fixing the install failures we have?"
Failed installs are a symptom of an environment nobody can see. Repairing one after the fact means guessing what is already on the disk and what put it there. This removes the guess rather than getting better at it. It does not stop incremental fixes.
"Does this compete with what we already sell?"
It does the same job as the existing install path, more reliably. Whether it replaces that path, feeds it, or sits beside it is exactly the decision this demonstrator is evidence for. That decision is open.
Section 6 of 7
Where it stops
The boundary matters as much as the demonstration, because a working system invites people to assume the rest is close behind.
- It does not detect, validate, repair or clean an existing game folder.
- It is not production quality. Scale, security review, error handling breadth, telemetry and accessibility are all out of scope.
- It commits to no manifest format, schema or implementation. Language, framework and storage were free choices for whoever built it, and nothing here argues for any of them.
- It does not solve manifest authoring at scale, or the workflow by which a community would contribute that data.
- It changes nothing in the mod publishing pipeline.
- It does not add mods to a list, support post-install steps, or help anyone curate.
- A handful of games, one store, one platform.
Section 7 of 7
What happens next
The demonstrator goes in front of people.
The question to decide
Does this show what good could look like for curated modding?
The feedback sets what gets planned from there: the next piece of research, and any production steps the decision justifies.
A next step
Naming the external partners who also see this, and deciding the terms on which they see it.
The questions still open
These come up most often. They are not the only ones open.
- Could one data schema carry several games, and what would it look like?
- Who authors and maintains that data, and through what workflow?
- Do manifests live in git so people can collaborate on them?
- When does leaving other game stores out stop being a reasonable thing to defer?
- Does pinning every input make the result too rigid, and where would that start to bite?