I want to start creating a simple multiplayer, JavaScript based, cross-platform game. Think about it as a two player mario where players can shoot each other.

My question is what is the best way (or at least a feasible way) to implement multiplayer into the game. I was thinking about:

  • Running the game on the both clients, from which one of them is considered to be the server and the other is playing catch-up.
  • Using my web server only to establish the connection between the two clients (and forward requests between them, I think this is easier then trying to use some RTC peer-to-peer protocol).

I have never done any multiplayer game, so I do not know if this method is good. One flaw in the design is that the game becomes very hackable (as the one that is considered to be the server has control over all the legal move validations done).

So, my question is if, using this method, a playable multiplayer game can be implemented, where if one player clicks the "shoot" button pointing in a specific direction the other player would receive this data in a period of time short enough so that he can react to it. If not, what is another reliable way to create a JavaScript, cross-platform (web, mobile) game?

If I were to also run an instance of the game on the server for each duel betwen two clients I think the servers would be over-loaded very easily, so I don't consider this a solution.

PS: About the hackable part. Do you think it can be reduced if I can somehow implement checkings on both clients?

PS2: When I say multiplayer I mean over the internet, not a local ad-hoc multiplayer for mobile devices.


When you say "Javascript" you certainly mean "running in the web browser". In that case, peer-to-peer networking isn't possible because there is no browser-independent standard for this.

But what you can do is having a server. One technology which is quite well-suited for real-time games are websockets. You can prevent most kinds of cheating by having an authoritative server which implements all game mechanics and sends the clients the results.

| improve this answer | |
  • \$\begingroup\$ Yes, I know about websockets, I played with them a bit. P2P in browser is supported via webRTC, which unfortunately will not work very well on mobile platforms, as very few support it. As I said, my multiplayer game will only be a two player multiplayer game, so running the game on the server means that I will have to run the game for each and every player duel, which will require a hell of a server. I was looking for a better architecture solution. \$\endgroup\$ – Cristy Jan 24 '15 at 16:22
  • \$\begingroup\$ My final goal would be creating a two player multiplayer game for desktop browser and then simply using CocoonJS or PhoneGap to bring it to mobile devices. So, I also want to know if this transition will rise any problems (when talking about the multiplayer part) ? \$\endgroup\$ – Cristy Jan 24 '15 at 16:27
  • 1
    \$\begingroup\$ @Christy how much it will burden your hardware depends on implementation details. But I made the experience that most games don't scale linearly but quadratically with the number of players which interact in the same area, so having 50 matches with two players each the same time can be less resource-intense than 100 players in one match. \$\endgroup\$ – Philipp Jan 24 '15 at 16:28
  • \$\begingroup\$ I also posted this question here (even though there are other similar questions) because I want the answer to directly relate to JavaScript capabilities. \$\endgroup\$ – Cristy Jan 24 '15 at 16:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.