8
\$\begingroup\$

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.

\$\endgroup\$
6
  • \$\begingroup\$ 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? \$\endgroup\$
    – Will
    Sep 9, 2011 at 13:55
  • \$\begingroup\$ The server is running on my netbook which runs Ubuntu Linux, and it is written in server-side JavaScript, which runs using node.js. \$\endgroup\$
    – jcora
    Sep 9, 2011 at 14:04
  • \$\begingroup\$ 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. \$\endgroup\$
    – jhocking
    Sep 17, 2014 at 15:37
  • \$\begingroup\$ 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. \$\endgroup\$
    – jhocking
    Sep 17, 2014 at 15:41
  • 1
    \$\begingroup\$ I don't know what mods think but I like it a lot better now. back to upvote \$\endgroup\$
    – jhocking
    Sep 17, 2014 at 16:06

4 Answers 4

9
\$\begingroup\$

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.
\$\endgroup\$
2
  • \$\begingroup\$ Yes, I am doing these things. \$\endgroup\$
    – jcora
    Sep 9, 2011 at 13:14
  • 10
    \$\begingroup\$ Please notice that these instructions are valid for every multiplayer game, regardless of language, platform or whatever. \$\endgroup\$
    – o0'.
    Sep 9, 2011 at 14:38
10
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ Thanks a lot. I will edit my post and describe the game now. \$\endgroup\$
    – jcora
    Sep 5, 2011 at 20:04
  • 3
    \$\begingroup\$ never never never never never trust the client, whether its javascript or something else! \$\endgroup\$
    – erik
    Sep 5, 2011 at 21:10
  • 1
    \$\begingroup\$ While all game clients are indeed hackable, some are more hackable than others. \$\endgroup\$ Sep 6, 2011 at 13:32
  • 2
    \$\begingroup\$ 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? \$\endgroup\$
    – jhocking
    Sep 6, 2011 at 17:26
2
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .