Proposal: Improve match-making routine

I’d like to propose a change in the API, to allow restructuring of the match-making process, and avoid unexpected issues during its process.

The proposed API here is not final. I’d love to hear your thoughts about it!

Current behaviour

Currently, the match-making process may cause unexpected issues due to async rooms being disposed in the middle of the process, like https://github.com/gamestdio/colyseus/issues/174

On the client-side, the room instance is immediately created even though the room might not be successfully created.

const room = client.join("my_room", { /* options */ });
room.onJoin.add(() => console.log("joined successfully!"))
room.onError.add(() => console.log("room couldn't be created?"))

• This API can be confusing since both room creation errors, and regular room errors are dispatched into the same handler, without a differentiation between them.
• It’s not possible to determine whether a join error was caused by wrong credentials (onAuth) or a bug in the server.

Desired behaviour

The server can make extra-checks during the match-making process to avoid this error (https://github.com/gamestdio/colyseus/issues/174), and provide better error handling in the client-side.

client.matchmake("my_room", {/* options */}, (err, room) => {
  if (err) { 
    console.log("match-making error: couldn't join into 'my_room'");
    console.log("reason:", err)
    return;
  }

  room.onJoin.add(() => console.log("joined successfully!"));
  room.onError.add(() => console.log("only room errors here"));
});

Version 1.0.0

As this is a big change in the API, I’m planning to have this on version 1.0.0.

[seiyria]

Anything to fix #174 sounds great to me! If the matchmake function can resolve this, I’m fine with it.

[oyed]

@seiyria I’m not entirely sure you’re in the minority - Colyseus is a netcode lib, not a matchmaking lib - attempting to do “too much” could easily take away what Colyseus is, a netcode lib. It would be nice to optionally have a built-in, simplistic, non-scalable matchmaking service like we currently do, however for the future, supporting something like mentioned in #179 would really benefit the library and allow @endel to focus on more important things.