Abstract Server

[nicolodavis]

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 allow multiplayer client creation to be overridden #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.

[Stefan-Hanke]

Err I'm puzzled what exactly you mean by your first two sentences. It should be possible to play a multiplayer game client-only for testing purposes? And by "singleplayer mode" you mean that the developer plays all players but always gets the view from the player that is on turn?

[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]

Another nice property we'll get out of this is the ability to run examples like the Militia card (which you authored yourself) completely on the browser (which will make it embeddable in the documentation).

[Stefan-Hanke]

Actually I dislike the term "multiplayer" altogether because it connotates the need of a server to be playable. Which is not the case. The game itself defines with how many players it can be played, regardless of the use of a server. I'd not use "non-networked" also since it's a negation. Whatever we come up with should be reflected in the source or anyone reading "multiplayer" (client.js, l94ff) will have to translate mentally what it actually means.

[amitport]

@Stefan-Hanke. made a few similar engines. Usually called this interface GameMaster (doesn't have to be remote, keeps track of the game secret state. While we're on architecure: LocalGameMater is mostly same as the current regular GameReducer while RemoteGameMaster is the multiplayer game reducer which should receive a Transport interface specifying the pubsub etc API (socketIOTransport for example)

[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.