Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What are the possible downsides to using (client side) JavaScript when creating a multiplayer game?

Game description: It's an MMORPG/RTS. That means players actively contribute to structures in the world and create much of the content themselves.

share|improve this question
I'm curious: what mechanism do you use for the client to talk to the server, and what's the latency like? What platform are you using for the server? – Will Sep 9 '11 at 13:55
The server is running on my netbook which runs Ubuntu Linux, and it is written in server-side JavaScript, which runs using node.js. – jcora Sep 9 '11 at 14:04
I don't know why I originally upvoted this question. Changed to a downvote and considering casting a close vote, because "is ___ a good idea?" is never really an answerable question. Indeed, in my answer I even pointed out that the question can't exactly be answered. – jhocking Sep 17 '14 at 15:37
Also, I feel like changing the title to "Is a multiplayer game in JavaScript a bad idea?" would improve the question. At first that seems like a trivial change, but recasting the question as looking for downsides makes it more answerable than a "which tech should I use?" kinda question. Asking "is this tech good?" just invites axe-grinding. – jhocking Sep 17 '14 at 15:41
I don't know what mods think but I like it a lot better now. back to upvote – jhocking Sep 17 '14 at 16:06
up vote 9 down vote accepted

It's fine if:

  1. The server doesn't send any information about players behind local player's field of view (must be calculated serverside) to the local player (to prevent wallhacking).
  2. All actions are checked for availability on server when a player presses action button.
  3. You only render on client - all actions are done on server and only predicted on client.
  4. All timed actions are serverside.
share|improve this answer
Yes, I am doing these things. – jcora Sep 9 '11 at 13:14
Please notice that these instructions are valid for every multiplayer game, regardless of language, platform or whatever. – o0'. Sep 9 '11 at 14:38

Whether or not your game is a good fit for JavaScript development depends on the game. You didn't describe your game, so there's no way for us to answer the question in the title.

However I can say that your hacking concern is not a problem here. Not because JavaScript can't be hacked (it can, and easily) but so can every other client-side technology. One of the basic tenets of multiplayer game development is "never trust the client". Design your game in such a way that anything you need to protect from hacking is running on the server, because the client will be hacked. This means only send UI commands from the client (eg. "the player clicked the Bomb button") and calculate the results of player actions on the server. Then the server sends back to the client the results of those actions.

Since no matter what technology you relied on you should design your game with the assumption that the client-side component will be hacked, the hackability of JavaScript isn't a consideration when deciding whether or not to use JavaScript.

share|improve this answer
Thanks a lot. I will edit my post and describe the game now. – jcora Sep 5 '11 at 20:04
never never never never never trust the client, whether its javascript or something else! – espais Sep 5 '11 at 21:10
While all game clients are indeed hackable, some are more hackable than others. – Jonathan Connell Sep 6 '11 at 13:32
That is true, but the distinction is irrelevant. When designing the security for your game, what does it matter if option A is harder to hack than option B if they will both be hacked? – jhocking Sep 6 '11 at 17:26

People can change the client code in order to cheat, that is a problem for any multiplayer game. If reaction speed or speedy solving of mathematical tasks is a part of the game you can't completely prevent cheating.

For any other game element you must ensure that the client won't and can't obtain information that is supposed to be hidden to the player. And of course the server must validate that every action taken by a player is legal.

The greatest problem I see in JavaScript games is that a lot of browsers have a tendency to stutter, especially Firefox was pretty bad last time I checked. For this reason JavaScript is not a good choice for timing-sensitive gameplay. But for turn-based or at least slow-paced games JavaScript can work quite well.

share|improve this answer

Changing Javascript variables is pretty easy to do with tools like Firebug (for firefox) or the build in dev tools of Safari/Chrome. You can simply type in javascript in the console and it'll get executed. As a simple rule, do not rely on the client side for security. Apart from that, with the introduction of the HTML5 canvas element, javascript offers you some real possibilities for simple games (There is a full javascript/html5 version of Angry Birds for instance).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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