MagicBeanDev/Longshot

Watch

Fork 71

Idea: co-op from playtest to merge: a tester build without merging, a merge switched off, and the relay #463

New issue

Open

opened 2026-11-14 15:38:06 +00:00 by mooki · 1 comment

mooki commented

2026-11-14 15:38:06 +00:00

Member

The idea

Co-op is far enough along that it needs more players than its author can supply, and a decision on how it reaches them. This issue is for that discussion. It has three parts: testing it before any merge, merging it switched off, and the relay. Each ends in a question for the maintainers.

The work is in #355 (work in progress), on top of #68 and #51 . The commit testers use today is 2f01e1b4bdb6e1629c54a998f0403519fe4e5c74. A newer one follows today (another player's Link stays in place through a stall of up to 10 seconds, and the Co-op tab says Experimental); the test requests move to it once it is proven.

Where it stands. Shown so far: two games on one PC (six two-game checks, a 30-minute session), a Linux PC and a Windows PC playing together on a home network, and one Windows tester's native run. Not shown yet: a Mac, three or more players, a session across the internet, save transfer on Windows.

1. Testing it before any merge

Today a tester has to build the commit from source (the guide is the first comment of 355). That limits testing to developers.

The launcher offers Stable, Release candidate and Nightly, all built from main (docs/versioning.md), so it cannot offer this.
#337 with #353 and MagicBeanDev/LongshotLauncher#59 would let the launcher install a pull request's build. That is the right long-term route. As written, 353 builds pull requests that are not drafts, and 355 is one.

Proposed:

Now: a separately labelled builder download made from an agreed co-op commit, by running the existing Windows and Linux builder workflows by hand on a playtest branch. Players still build the game on their own PC from their own copy; nothing made from the game is distributed. The playtest starts with its own user folder, so normal saves are not touched, and it names its exact commit so everyone in a room runs the same one.
Later: once pull request builds exist, a way to opt a draft in (a label, say), so co-op rides on that instead of a special download.

Question 1: would a maintainer run the two builder workflows on a playtest branch and publish the result as an experimental download? If not, what would you want instead?

2. Merging it switched off

In #42 I asked whether co-op should be the first module of a mod interface and said I would accept the delay. I now propose the other order, because a module interface is a larger decision than co-op and should not be rushed by it:

Core first, in this order: 51 (text fields in the menu), then 68 (rooms, the relay, accepted progress sync, the Co-op tab), then 355 in reviewable pieces: signed rules, consent and ownership; other players' bodies; save isolation and transfer; the optional social, travel and practice parts.
Off by default. Co-op does nothing until the player makes or joins a room. A measurement of what the switched-off code costs per frame comes with 355.
Marked Experimental, in one of the ways below.
Behind a module interface later, if 42 lands one. Nothing in this order prevents that.

What "Experimental" could mean, for you to choose:

a. As built: off by default, and the Co-op tab carries the word Experimental, in every channel.
b. A switch: the Co-op tab stays hidden until the player turns on experimental features.
c. Not in Stable for now: present in Nightly and Release candidate builds only.

Question 2: is core first, off by default, in that order acceptable, or should co-op wait for the module interface?

Question 3: which meaning of Experimental, a, b or c?

3. The relay

Players host by default. The player who makes a room can host it from the game on their own PC, with one UDP port open. No shared server is needed to play.
A relay helps players who cannot open a port. It is a small program (scripts/coop_relay.py in 68). It forwards packets between the members of a room. It sees addresses, display names and room identifiers; it cannot read what the players send, which is encrypted with a key made from the room secret that the relay never gets.
For the playtest I run one relay on a server of my own, for invited testers only, each tester's address allowed by hand. Before that, two limits go into the relay: a rate limit on its control replies, and a bound on one per-room list. Without them a hostile client could waste its CPU and bandwidth, so it is not opened wider until then.

Question 4: does the project want an official relay later, and if so who would run and own it? If not, co-op stays player-hosted, with community relays for those who run one.

Anything else

This does not ask for 355 to be reviewed or merged as it is. It is still work in progress, and its open test requests are T-ADK4, T-QF6F and T-KQUM.

### The idea Co-op is far enough along that it needs more players than its author can supply, and a decision on how it reaches them. This issue is for that discussion. It has three parts: testing it before any merge, merging it switched off, and the relay. Each ends in a question for the maintainers. The work is in https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/355 (work in progress), on top of https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/68 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/51 . The commit testers use today is `2f01e1b4bdb6e1629c54a998f0403519fe4e5c74`. A newer one follows today (another player's Link stays in place through a stall of up to 10 seconds, and the Co-op tab says Experimental); the test requests move to it once it is proven. **Where it stands.** Shown so far: two games on one PC (six two-game checks, a 30-minute session), a Linux PC and a Windows PC playing together on a home network, and one Windows tester's native run. Not shown yet: a Mac, three or more players, a session across the internet, save transfer on Windows. #### 1. Testing it before any merge Today a tester has to build the commit from source (the guide is the first comment of 355). That limits testing to developers. - The launcher offers Stable, Release candidate and Nightly, all built from main (`docs/versioning.md`), so it cannot offer this. - https://git.magicbean.dev/MagicBeanDev/Longshot/issues/337 with https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/353 and https://git.magicbean.dev/MagicBeanDev/LongshotLauncher/pulls/59 would let the launcher install a pull request's build. That is the right long-term route. As written, 353 builds pull requests that are not drafts, and 355 is one. Proposed: - **Now:** a separately labelled builder download made from an agreed co-op commit, by running the existing Windows and Linux builder workflows by hand on a playtest branch. Players still build the game on their own PC from their own copy; nothing made from the game is distributed. The playtest starts with its own user folder, so normal saves are not touched, and it names its exact commit so everyone in a room runs the same one. - **Later:** once pull request builds exist, a way to opt a draft in (a label, say), so co-op rides on that instead of a special download. **Question 1:** would a maintainer run the two builder workflows on a playtest branch and publish the result as an experimental download? If not, what would you want instead? #### 2. Merging it switched off In https://git.magicbean.dev/MagicBeanDev/Longshot/issues/42 I asked whether co-op should be the first module of a mod interface and said I would accept the delay. I now propose the other order, because a module interface is a larger decision than co-op and should not be rushed by it: - **Core first, in this order:** 51 (text fields in the menu), then 68 (rooms, the relay, accepted progress sync, the Co-op tab), then 355 in reviewable pieces: signed rules, consent and ownership; other players' bodies; save isolation and transfer; the optional social, travel and practice parts. - **Off by default.** Co-op does nothing until the player makes or joins a room. A measurement of what the switched-off code costs per frame comes with 355. - **Marked Experimental**, in one of the ways below. - **Behind a module interface later**, if 42 lands one. Nothing in this order prevents that. What "Experimental" could mean, for you to choose: - **a.** As built: off by default, and the Co-op tab carries the word Experimental, in every channel. - **b.** A switch: the Co-op tab stays hidden until the player turns on experimental features. - **c.** Not in Stable for now: present in Nightly and Release candidate builds only. **Question 2:** is core first, off by default, in that order acceptable, or should co-op wait for the module interface? **Question 3:** which meaning of Experimental, a, b or c? #### 3. The relay - **Players host by default.** The player who makes a room can host it from the game on their own PC, with one UDP port open. No shared server is needed to play. - **A relay helps players who cannot open a port.** It is a small program (`scripts/coop_relay.py` in 68). It forwards packets between the members of a room. It sees addresses, display names and room identifiers; it cannot read what the players send, which is encrypted with a key made from the room secret that the relay never gets. - **For the playtest** I run one relay on a server of my own, for invited testers only, each tester's address allowed by hand. Before that, two limits go into the relay: a rate limit on its control replies, and a bound on one per-room list. Without them a hostile client could waste its CPU and bandwidth, so it is not opened wider until then. **Question 4:** does the project want an official relay later, and if so who would run and own it? If not, co-op stays player-hosted, with community relays for those who run one. ### Anything else This does not ask for 355 to be reviewed or merged as it is. It is still work in progress, and its open test requests are T-ADK4, T-QF6F and T-KQUM.

mooki referenced this issue

2026-11-14 15:38:13 +00:00

Idea: install a pull request's build from the Longshot Launcher, to help test it #337

mooki referenced this issue

2026-11-14 15:43:58 +00:00

Idea: one path for randomizers, restoration mods and co-op, with a mod interface in tiers #42

mooki commented

2026-11-14 17:19:29 +00:00

Author

Member

Update, 14 November: the direction I now prefer. To be confirmed in this thread; nothing moves until then.

It changes part 2 and narrows part 3.

Merge first, as a module in its own repository

Co-op gets merged and shipped rather than living on as a long playtest branch, but its code goes into a separate repository on git.magicbean.dev, loaded as a module by the mod launcher (the mod work in #134 and the tiered interface in #42).
Why: it keeps co-op portable. The module can move at its own pace beside Longshot's releases, a player opts in by installing it, and a port with the same interface could use it too. It also keeps a large feature out of the core's review queue.
What it implies: Longshot needs the small, versioned native-module interface that issue 42 calls tier 4, with co-op as its first consumer. That was my first preference in 42, and this returns to it. The exact hooks still have to be listed from 68 and 355 (roughly: the local player's state each frame, drawing other players, a menu tab, the save folder, the network); that list is the next step, not settled here.
Meanwhile 68 and 355 stay open as the reference implementation and for testing. 51, the menu's text fields, is already merged.

The relay: undecided

For testing I host one relay on a server of my own, for invited testers only, with the two limits from part 3 added first.
Dedicated project infrastructure can come later. Whether there is an official relay and who runs it stays open (question 4).

The questions, updated

Question 2 becomes: is a separate co-op repository on git.magicbean.dev, loaded as a module, acceptable, with the module interface designed alongside it?
Question 3 (what Experimental means) may matter less: a module the player installs is opt-in by nature. It still applies to the interface itself.
Questions 1 and 4 stand as written.

**Update, 14 November: the direction I now prefer. To be confirmed in this thread; nothing moves until then.** It changes part 2 and narrows part 3. #### Merge first, as a module in its own repository - Co-op gets merged and shipped rather than living on as a long playtest branch, but its code goes into a separate repository on git.magicbean.dev, loaded as a module by the mod launcher (the mod work in https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/134 and the tiered interface in https://git.magicbean.dev/MagicBeanDev/Longshot/issues/42). - Why: it keeps co-op portable. The module can move at its own pace beside Longshot's releases, a player opts in by installing it, and a port with the same interface could use it too. It also keeps a large feature out of the core's review queue. - What it implies: Longshot needs the small, versioned native-module interface that issue 42 calls tier 4, with co-op as its first consumer. That was my first preference in 42, and this returns to it. The exact hooks still have to be listed from 68 and 355 (roughly: the local player's state each frame, drawing other players, a menu tab, the save folder, the network); that list is the next step, not settled here. - Meanwhile 68 and 355 stay open as the reference implementation and for testing. 51, the menu's text fields, is already merged. #### The relay: undecided - For testing I host one relay on a server of my own, for invited testers only, with the two limits from part 3 added first. - Dedicated project infrastructure can come later. Whether there is an official relay and who runs it stays open (question 4). #### The questions, updated - **Question 2** becomes: is a separate co-op repository on git.magicbean.dev, loaded as a module, acceptable, with the module interface designed alongside it? - **Question 3** (what Experimental means) may matter less: a module the player installs is opt-in by nature. It still applies to the interface itself. - **Questions 1 and 4** stand as written.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MagicBeanDev/Longshot#463

No description provided.

Rows
Columns