Generic Lobby improvements

[nicolodavis]

Ideas for improvement:

• Poll for changes to state so that refreshes are not required. (done in lobby auto refresh + leave game ready to play #510)
• Option to automatically remove room if all users leave the room (made the default behaviour in server: add new API endpoints 'list' and 'leave' #276)
• Add optional unique name check
• Add optional limit for rooms (will disable 'create room' button if rooms number reached limit)
• Provide ability to customize ui when waiting for an API call (i.e. loading state)
• Rename gameInstances to rooms (easier to understand). (done in More refactoring for lobby #406 and then re-renamed to matches in Fix #703 - Use the term "match" in the API and Lobby #704)
• Show leave button even if the game is ready to play. (done in lobby auto refresh + leave game ready to play #510)

EDIT: Design document by @flamecoals: link

[vdfdev]

Why don't we use websockets instead of polling?

[lehaSVV2009]

Why don't we use websockets instead of polling?

I think, websocket is better. Polling is just simpler to implement and no need changes on backend

[blunket]

IMO polling is better for this, sockets are overkill when it's just a lobby and doesn't need to be real time

[nicolodavis]

I think polling is better for the current feature set. We could add websockets when we have a chat room etc.

[lehaSVV2009]

btw, I also thought that lobby API might be improved a bit as well. To smth like that:

GET /games
GET /games/my-game/rooms
POST /games/my-game/rooms
POST /games/my-game/rooms/123/join
POST /games/my-game/rooms/123/leave
DELETE /games/my-game/rooms/123

[vdfdev]

One use case I want to bring to everybody's attention... My project will have several games, and I want people to choose the game after creating the lobby. And after a game is done, I want people to be able to play another game with the same people.

Is it ok if we key only by lobby id instead of both game and id? I can work on this latter

[blunket]

@flamecoals What do you mean? Multiple lobbies? Couldn't you just filter which games to display however you like? Or do you mean the games will be hosted on many different game servers too, or something like that?

Right now players choose the game to play IN the lobby, they don't create lobbies.

[nicolodavis]

Yes, I'm envisioning just one global lobby, and you can create games inside that lobby (each game can be a different kind). Players then join the game you created in order to play.

[vdfdev]

@blunket I meant one global lobby like Nicolo said. Basically a "room" persisting across matches too, of different types of games.

Use case:

• My friend Joe and I want to play some games, but we dont know exactly which game
• I create a game in the lobby for us, and I invite Joe
• We agree in playing Chess inside that game
• After the chess match is done, we go back to the same lobby and agree in playing tic tac toe

and so on

[blunket]

I see, I think you mean sort of like a party system? That'd be cool.

[vdfdev]

Hey folks, I started a document for the requirements and designing all these ideas we were talking about:
https://docs.google.com/document/d/1K0xDlyS_80WJic7GfNobl-SujfC8_LiB55-JJnAawNM/edit?usp=drivesdk

Still WIP, but feel free to comment or add anything I am forgetting. I will update this thread whenever I think it is ready for review.

[vdfdev]

Hey folks, I finished the first pass of the design document for the lobby:
https://docs.google.com/document/d/1K0xDlyS_80WJic7GfNobl-SujfC8_LiB55-JJnAawNM/edit#

Please give any feedback :D

Just so nobody freaks out, I won''t do this in a single PR. I just want to get an agreement that this is the desired state and we can do small PRs towards that goal. See Development Plan section.

@nicolodavis It would be great if you could give me some clarity around "Open questions" section

[nicolodavis]

@flamecoals Sent you some comments on your doc.

[vdfdev]

Ok, @nicolodavis, I replied to them. Given the points you asked are not questioning the overall idea, I think we are more or less in agreement on the path forward. I will start sending PRs so we can start implementing this. :)

[nicolodavis]

I think we should have agreement on the user data storage part first, because that's a critical design feature.

Feel free to implement any of the items that don't touch that yet though.

[vdfdev]

Ok :)

[francoijs]

Bravo for the lobby design proposal and the documentation!
I've added a few things in the description of the current behavior.

[vdfdev]

@francoijs Thanks for the help! Approved all your suggestions. I will probably do the first PR soon on this.

[nicolodavis]

@flamecoals @francoijs @jasonharrison

Do you guys have thoughts about what to do about the Lobby in the Svelte world (after #432)? We can migrate the lobby rendering components to Svelte (easy), but I'm not sure how to then hook it into the board components that users create, which might be in React / Angular or whatever.

We want the lobby to be in something generic like Svelte so that folks using the vanilla JS client also have access to it. However, if the user chooses to code their board in React, we want the lobby to be able to instantiate it as well.

[nicolodavis]

Perhaps we should use a generic render callback of some sort that the user can use to the render the game using any technology of their choice?

Current State

We pass in the React components to the lobby directly (which is itself a React component). The Lobby then knows which component to render based on the game selected.

<Lobby gameComponents={ ... } />

Proposal

Once we migrate the Lobby to Svelte (or even if we keep it in React for that matter), I think we should expose it as a function to the end user (rather than a component).

import { Lobby } from 'boardgame.io/lobby';

const lobby = Lobby({
  games: [ ... ],

  render: (gameName, playerID, gameID, root) => {
    // This function is called once the player has chosen the game and hits "Play".
    // We can render a component using any framework of our choice
    // (including React as shown below).  We should also consult gameName
    // before deciding which component to use (not shown in this example).
    // root is just a HTMLElement on which we render our client.
    ReactDOM.render(<TicTacToe gameID={gameID} playerID={playerID} />, root);
  },
});

lobby.run();

We can also preserve the convenience of our current approach by providing a bundled renderer for React:

const lobby = Lobby({
  games: [ ... ],

  render: ReactRenderer({ gameComponents: { ... } }),
});

[delucis]

Is src/lobby/connection.js currently useable as a vanilla “lobby client”? Mirroring trying to develop the vanilla game client (supporting events etc.), it would be nice if there was something users could plug their own lobby rendering into that provides the basic API (list, join, leave, etc.)

[delucis]

Also, looking at this, it looks like an extra dependency might be needed to allow a Svelte Lobby to handle React components (and more dependencies for more frameworks). Maybe it would be better to have framework-specific packages that sit on top of the vanilla client and lobby APIs and provide components in React, Vue, etc.? (Svelte Client and Lobby components could still be used by those not using frameworks.)

[nicolodavis]

Why would we need to pull in react-svelte? Wouldn't the React dependencies be the responsibility of the developer using boardgame.io?

import { Lobby } from 'boardgame.io/lobby';

// These are in user code.
import React from 'react';
import ReactDOM from 'react-dom';

const lobby = Lobby({
  games: [ ... ],

  render: (gameName, playerID, gameID, root) => {
    ReactDOM.render(<TicTacToe gameID={gameID} playerID={playerID} />, root);
  },
});

lobby.run();

[delucis]

Ohhhh, I see — react-svelte is if you need to use React in your Svelte app before compiling it. Then the above looks great!

Do you think there should be some documentation on how to use LobbyConnection directly for those who don’t want to use the provided component?

[nicolodavis]

LobbyConnection is just a simple REST client that invokes our API. Do you think there is much value in making that externally visible? I would think that people would prefer to use their favorite library to call our REST API directly as opposed to using our client wrapper.

[nicolodavis]

My thinking was that we just provide the REST API (which can be consumed in many ways). In addition to that, we also provide a default lobby implementation (that can be styled). If someone wants to build a completely different lobby, they can go ahead and build that on top of our REST API.

What we should be focusing on is making our existing lobby generic enough that people won't see the need to re-implement it.

However, I can see some value in providing a client-side abstraction if we want to hide the communication between client and server (for example, if we want to start using sockets). Maybe we should revisit this idea once our lobby implementation is starting to do complex things like that.