Going multiplayer

[Jackolantern]

Multiplayer architecture is quite different from single-player. In multiplayer, all the real game logic is occurring on the server, and the client is simply running logic to display what it receives from the server. You also have to deal with network latency. You could make it single-player first, but you would have to cut up the game pretty severely to re-assemble it into a multiplayer game.

[Jackolantern]

You would definitely want a fair bit of single-player HTML5 experience before tackling a multiplayer game, as it is most definitely a step-up in difficulty.

[Jackolantern]

"HTML5" became an umbrella term for many of the new features being added, including piles of new semantic HTML tags, the canvas tag, and new Javascript APIs. I guess the name "HTML5 games" stuck because the browser has to support HTML5 to have support for canvas.

[a_bertrand]

Actually you have 2 roads to make a game multiplayer and the separation of the logic between server and client. Each offer advantage and drawbacks:
- Run most of the code on the client side and use the server just as "relay" to pass the messages between players as well as save a state.
- Run most of the logic on the server side and use the client just to display and interact with the players.

Advantage of the first one, is that it will allow you to scale more easily as most of the logic will be handled by the client itself and the only thing which really needs to scale on the server is the bandwidth. Yet if you wasn't on web, you could even think about peer-to-peer networks where basically there is nearly no center server. This advantage of reduced load on the server has however some drawbacks in term of easier to hack, as if you don't do the actions on the server, being able to add "gold" to your own player should be matter of incrementing some memory variable. You will also have issue with monsters and their AI, who will control the AI of a monster? And what happen when a client disconnect? Should the monster be handled by another player at that time?

The second design makes easier to control what's happen as all the "dice rolling" or action logic is on the server side. However this has the major drawback of requiring a process running all the time to handle the virtual world and you will consume a lot more server resources for it.

You could end up having mixed design with more or less logic on one side, yet fundamentally you have those 2 options, run something on the server and control it, or leave it on the client and save server resources.

BTW if you choose the first option where nearly all runs on the client side, you could still have some cross check or simply statistics, and guess that if a player played only 5 min and yet produces tons of gold, maybe he's a cheater

[Jackolantern]

- Run most of the code on the client side and use the server just as "relay" to pass the messages between players as well as save a state.

You touched on this, but wouldn't the real issue of doing it this way is that you couldn't verify state? State is in constant flux when the Internet and latency is involved, and without an arbiter, every client will claim their state is the correct one. For example, if 2 players are racing towards an item on the ground, and player A registers a click to grab it within 10ms of player B registering a click to grab it, they would both appear to be the only one who grabbed it and took possession of it. A rift has now been created, and the players are now playing in their own version of the world. Server logic is needed to be the arbiter of state, and whoever got their click to the server first is awarded the item, and all clients are notified of the winner.

How would state rifts be handled in this setup? I think even "client-based" FPS multiplayer games have to choose a user's game console to act as the server.

EDIT: I am not trying to say it can't be done, because I know you have a lot more experience than I do in writing multiplayer browser games and am more interested on your take on how to solve this.

[a_bertrand]

Right, if you handle things like that, where 2 players runs after 1 single object found on the map, you may have issues having the client handling the whole. Personally, I would limit the "multiplayer" interaction, in such that actually you would see each others, you could trade with each other, but many things would actually separated, to avoid such "race" condition.

Think that, anyhow, you will have issues on the net because nothing is realtime, and players will have the "lag" effect where their commands may take time before being executed by the server. Even with websockets (which are not supported till IE 10 on IE), you will have delays and some times long one. So you need to have a playable game, some sort of delay compensation on the client side, and it means basically that the client is responsible for example of the player movement.

Overall, I will go for a limited multiplayer solution, where even monsters / animals may not be shared across the players. I know it may seems odd, but server resources are for me way too expensive to be increased like that, as well as the technology is not yet here to allow me just with JS to make a true multiplayer game compatible with 90% or + of the browser market.