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

I'm developing a multiplayer game in PHP/jQuery, and naturally have to be wary of any sort of data coming from the client.

At present, I have tables of data representing the map (2D roguelike), monsters, items, and player(s). Initially, my thought was to simply package it all in a JSON object and send it every game tick, however when actually looking at the data I realized that's quite a large packet to be sending.

So, my question is what is a good approach for minimizing data sent to the client? Obviously I would need to figure out some way of validating whatever it sends back. Initially we'd hoped to do some minimal verification on the client-side, but each time we thought of one thing we could do it is immediately invalidated with tools like Firebug.

Kind of an open question I realize, but we want to get this right before we move on with our implementation so we don't have to shoehorn in bugfixes later on.

share|improve this question
Are you sure that you need to send data at every tick (it's real time, or in discrete turns?)? I'm currentely in VERY early stages of implementing a Canvas/Online-validated action rpg, but I'm only send requests at certain/significant actions, and I'll only send/retrieve data for the affected entities. – Billy Ninja Oct 19 '12 at 20:59
I forgot to mention this will be a multiplayer roguelike, so the ticks represent querying the server for an updated game state. – espais Oct 20 '12 at 2:34
up vote 3 down vote accepted

Depends on what information they are already expected to have. For example, if they have the map already on their client, then you only need to send information about non-static things within the map. If they don't have the map then you should try and only send them map data for the area that they're in, and, when sending them information about non-static objects, only send those for the area that they're in as well.

For a 2D game I would have an axis-aligned rectangular/square region (on the server) that represents the area that encompasses everything they would need to know about based on their location. Send them information about objects when they enter the region, and then send them updates on those objects whenever the state of that object changes, then you can send them a small packet when something leaves that area so that they know to delete it from their client. By doing this on the server the server will have a list for each player of the objects that the player cares about and has loaded on their client, and so whenever any object's state changes in a way that a client may care about, have that object call a method on the server that checks if any player currently has that object in range, and if so then you can prepare a packet for that player. I've seen this architecture work on a shipped and successful MMO, I'm sure it could be done for a 2D game as well.

share|improve this answer
When you mention 'expected to have' that is exactly what we are trying to nail down right now. We're considering sending an initial map state to the client, storing it in the HTML5 offline storage and not worrying about security on that as much. More so checking to ensure that values are as expected. Good proposal though! – espais Oct 19 '12 at 20:33

Send the changes, not the data itself. Maps, items, monsters and players should be submitted once while loading, and then only send updates, like "player Z has moved to tile X, Y" or "tile X, Y has become water" or "monster Z shouted"

share|improve this answer
What worries me though is how easy it is to manipulate local data with Firebug or other similar tools. – espais Oct 21 '12 at 15:55

Consider compression of sending/receiving JSON data blocks between your server and clients.

Here is an article about LZW compression and decompression with JavaScript and PHP.

share|improve this answer

Regarding your question of data validation it should be performed both on the client and server sides, however it's important to determine which validation to perform where.

Any validation that does not necessarily require communication with the server can be implemented client-side. For example, a player moving to a position outside the boundaries of the map does not necessarily require communication with the server because the map is stored locally on their machine - however, you would still need to perform this validation on the server to handle the case where a malicious user has altered your client side code.

So why not perform all validation on the server? The point is that by having some validation performed on the client you can reduce the number of requests made to the server, providing the player with immediate feedback, saving cpu time and bandwidth. The majority of players are not malicious so it is a 'quick win'.

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.