Abstract Server

Abstract away all the business logic in src/server/index.js into a class that can actually be run entirely on the browser. This will allow close to real testing of the multiplayer experience with one code path without having to run a socket server.

• This component will communicate via the network and storage interfaces (we already have a storage interface, but are waiting on #246 for a network interface).

• This will allow retiring all the “can player make move” checks inside reducer.js that the server already handles.

• We can also remove code like this which simulates a server effect (playerView in this case).

The first step will probably involve just refactoring src/server/index.js to move all the business logic inside a class with a clear interface. After that, once we have the ability to replace the socket layer with something ad-hoc that merely relays messages from one JS object to another, we can test this on the browser.

TODO:

• decouple server logic from transport layer.
• use Master on the client side always (even in a singleplayer game).
• remove redundant checks in the reducer / client code.
• update multiplayer.md to explain how masters work, and also document local: true.

[nicolodavis]

EDIT: Removed “singleplayer” from original post as it is confusing. I meant “non-networked”.

A multiplayer (i.e. networked) game can be played client-only at the moment, but it does so using a different code path. It does not go through server.js, which handles things like authentication and ensuring that only the correct player is allowed to play.

In order to simulate this experience, some of this code is duplicated in the game reducer.

Compare:

• https://github.com/google/boardgame.io/blob/master/src/core/reducer.js#L150
• https://github.com/google/boardgame.io/blob/master/src/server/index.js#L71

I’m proposing that we use one code path to do all this, i.e. instead of just playing actions on a game reducer on the client, we instead send actions to a “server” that does the usual processing and broadcasts the result back to the client. All of this runs on the browser, so it now becomes an accurate simulation of what happens when you connect a socket server and run over a network.

[nicolodavis]

@Stefan-Hanke I agree that the term “multiplayer” is not ideal, but for better or worse it is what people associate with a networked game in the video game world. This is the same terminology that Steam uses, for example. I think the term single player is more confusing. We should probably use the word “solo” to indicate games that have exactly one player and maybe “local” to indicate games that are non-networked.

The server component itself can probably be called master / runner / something else. If we are going to start using it locally, we should probably rename it to something other than server to avoid confusion.