I'm wondering if combining Javascript clientside with PHP/mysql serverside is a good idea for HTML5 real-time multiplayer (small scale) browser games?

My technical knowledge is very limited, and even though I plan on learn node.js in the future, the learning curve is rather huge right now.

Since I'm already familiar with PHP I feel I would get it functioning much faster.

The scale I'm thinking is 2-8 players at the time. And trying to keep the client to server message count as low as possible.

The values I intend to store/handle are:

  • Player name and ID.
  • X and Y position.
  • Health.
  • Equipped items (maximum 8 slots, probably less).
  • Actions (walk, attack, use etc but only 1 action/player at a time).
  • Bullet X,Y coordinates and trajectory.
  • Guild/Clan name.
  • And some basic chat/mailing function.

My guess is even though it's not the best solution, but aslong as I keep the logic small, that this is completely doable. Am I right?

  • 4
    \$\begingroup\$ Sounds perfectly doable. Why don't you just try it? Worst case, you spend some time learning, best case, you get exactly what you want. \$\endgroup\$ – William Mariager Jul 31 '12 at 10:43
  • 1
    \$\begingroup\$ Yeah but I imagine this would take some time creating, and I don't like wasting time, that's why I asked here. =) \$\endgroup\$ – justanotherhobbyist Jul 31 '12 at 10:58
  • 8
    \$\begingroup\$ If you learn something, the time wasn't wasted. ;) Something worth considering is, if you switch language, you'll be spending time learning the new language and learning networking at the same time, which means much more debugging to find where you went wrong. If you stick with what you know, you'll learn networking first, and then you can port it if it turns out to be inefficient, and next time someone asks a similar question, you'll know the right answer because you tested it. \$\endgroup\$ – William Mariager Jul 31 '12 at 14:06
  • 1
    \$\begingroup\$ Thats actually a good point \$\endgroup\$ – justanotherhobbyist Jul 31 '12 at 16:42

For a real-time game, you want to minimize latency. Here's two tips for achieving it, with notes about PHP and Node:

  1. Use WebSockets. They allow fast two-way communication between the server and the client. Using node.js here has the advantage that you can use the same JavaScript API on both ends of the pipe. There's also the wonderful socket.io module for node.js that provides fallback technologies to lesser browsers that don't support WebSockets. Googling a bit, it seems you can also use WebSockets from PHP if you really want to.
  2. Don't involve database in time critical data such as coordinates of fast moving objects. This means keeping them in memory, which is not particularly well suited for the traditional PHP use model of having it fire once for each request to apache (or whatever web server), but you can launch your PHP server app also as standalone. I'd guess Node, with its V8 core, is going to be faster than PHP though. Whether that's an issue depends on how demanding your game is and how powerful the server is.

I myself find node.js very easy to pick up and since you are going to need to code quite a bit of JavaScript anyway, I'd recommend you try it. At least take a quick look at the socket.io tutorials to see how trivial it is to set up a real-time communication channel.

  • \$\begingroup\$ +1 for point 2. The biggest mistake you can make with this is expecting MySQL queries to fire on each event. Anything you can do to move the game data off the HDD is going to help. I've had success with abusing Memcached for this. There are undoubtedly other ways. \$\endgroup\$ – DampeS8N Jul 31 '12 at 12:45
  • \$\begingroup\$ Yeah I really want to learn node, but I have yet to get it to start from cmd even, the biggest mistake the developers made was to make it so difficult to get into. Atleast now the windows version comes with an installer, might give it a try if I find a good tutorial. \$\endgroup\$ – justanotherhobbyist Jul 31 '12 at 16:46
  • \$\begingroup\$ Node is not at all hard to start or use. Harder than PHP is, yes, but PHP pays a terrible price for its convenience - the design that lets it be embedded into Apache and on by default everywhere with no configuration also causes a lot of problems that make PHP utterly and absolutely the worst choice you can make for a real time game backend. Node, Python, Ruby, Java, etc all require you to set up the app server, but that very model allows highly scalable event-driven in-memory processing that is literally impossible to achieve in PHP. \$\endgroup\$ – Sean Middleditch Aug 1 '12 at 20:07

Along with Tapio's answer I would like to suggest to only (if possible) send user input (clicks and keyboard input) to the server, and having both server and client emulate the game. Every N ticks the client would ask the server for a sync, and the server will reply with all the information the client needs to render the game such as health, items, etc. This is to make sure the client doesn't get desynchronized too much.

Of course both the server and the client will need to have the exact same implementation of the game so this might be a bit more work. If you have perfect implementations on both client and server, the client will need to sync less often.

This will reduce client/server messaging and this reduce latency. This would also help prevent cheating.

Assuming you are creating this game in JavaScript, it might be worthwhile to write the back-end in JavaScript as well, using NodeJS. This way you could reuse the JavaScript implementation of your game for both the server and the client.


I recommend learning Nodejs. If you already now Javascript, it won't be so difficult. I made a TRON Multiplayer game quickly with Nodejs, and it was my first day using it. (Oh, and the client was an HTML5 canvas; I was only sending key input, as mentioned in the other comments.)

Take a look at a module called nowjs. Good luck!


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