Possible enhancements

[Hypercubed]

I see that recently a couple of new maintainers were added: #1188

Here is my list of much needed improvements. I'm willing to do some (or all) of these as PRs if I get a 👍

• client.start should accept setupData and pass that along to game.setup.
• The entire game.ai object should be passed to bots. This would allow passing in objectives to bots.
• Ability to pass in bots that were instatiated outside of client. Would really help setting bot options in the UI.
• Expose CreateGameReducer. This is needed for custom bots. Edit: found it in boardgame.io/internal
• Ability to disable core plugins. ImmerPlugin and SerializablePlugin in particular add significant overhead when running simulations.

Hoping to see some renewed activity here.

[benbot]

I'll have to look into the first couple bullets, but I'm all for making some plugins (specifically immer) optional.

FWIW my main goals personally are:

modernize the build system a bit (I don't think we really need babel plugins anymore)

update our very old version of socketio and other insecure deps

See about breaking out koa and getting in express if possible as koa is all but dead.

With that, I think the project would be in a good place. I imagine it's pretty intimidating to come into this project while not having worked in the webdev era it was made in.

[nicolodavis]

On the topic of modernization, I'd also consider moving away from socketio entirely and just going with websockets.

[nicolodavis]

I've also had good success in https://boardgamelab.app/ with just having all clients subscribe to a game event feed via SSE and then issuing simple POST requests to make moves. There really isn't a need for a bidirectional communication channel.

[fladrif]

I've also had good success in https://boardgamelab.app/ with just having all clients subscribe to a game event feed via SSE and then issuing simple POST requests to make moves. There really isn't a need for a bidirectional communication channel.

I was contemplating this model as well for another part of my project, but I couldn't get a read on whether or not this would be better, and if so how. Websocket already seem to have so low an overhead in general that managing the SSE subscription might be the same, now with the overhead of having a separate post mechanism. Thoughts?

[nicolodavis]

I don't really think of the POST mechanism as additional overhead because every web app is going to have an API of some sort, so there probably already exists a mechanism to receive POST requests.

The main benefits of SSE that I see are:

• the client implementation (EventSource) handles disconnects automatically, so you don't have to write custom logic for retries.
• they're easier to scale to multiple machines (websockets require more carefully co-ordination and sticky connections).

At a lower level, everything is multiplexed over a single HTTP/2 connection, so there aren't any performance downsides either.

[benbot]

Multiplayer games are inherently bidirectional, so I think websockets are still a good fit in principal.

Tho... I can't really think of any hard reasons why. 😅
Maybe in a board game where the timing of things matters, POST requests could introduce latency on spotty internet connections.

At my job, we're going to be migrating from socketio to SSE pretty soon, so after that I'll definitly have a good handle on the upsides and downsides of both and probably a pretty good idea of what it'd take to migrate off.