How Much Would This Strain the Server

[Octet]

For my game, I am thinking of having a real time map displaying all the players positions. The positions shall be stored in the database as coordinates such as

$X = 5, $Y = 4

.

I was then thinking of having a script which shall loop around constantly and get the new positions and then re-position them on the tile map. The concern I have is that this shall strain the server greatly, I have considered putting a sleep() in for about ten seconds to reduce the strain but even with that in do you think it shall be too much?

The loop would be global, so it would only happen once as opposed to happening for every player but even so... not sure about it

What do you guys think? Too much?

[SilverStar]

It would depend on how many users you have.

[Octet]

It would depend on how many users you have.

It shouldn't as I am planning on making it global so it is only querying the database once and then it updates the table on a local basis. I did this because if I had it query the database every ten seconds, for every user then I would expect the server to be under huge amounts of strain, so instead it is only done once but I still have concerns that it is putting a lot of work on it.

[SilverStar]

But won't every user have their own respective position? I'm not sure I fully understand the concept.

[Octet]

But won't every user have their own respective position? I'm not sure I fully understand the concept.

My idea is that in the database there shall be a coordinate for each player, probably a single number so Pos = 4. That shall relate to a position in an array which shall be displayed as a map on the players screen. When the player is in game, every ten seconds they shall get an update from a variable holding that array (so every player that is online at the time shall query the array).

That array gets the information from the database, so this way the database is only queried once (which shall be the most intensive operation). I don't think the number of players in the database shall matter too much, providing each player isn't querying that database.

Not sure if that got my point across, do you think querying the database once then updating the players from the array shall be excessive work on the server?

[KyleMassacre]

Im not to sure but I think having an ajax/js system in place might lower the strain while dynamically updating the map. Again, I can be completely wrong.

Or another option maybe is to just have the refresh of the map run only when a user acesses the page instrad of having it in some sort of cron or running randomly or whatever.

Optimizing your query should also lighten the strain buy just calling out columns required like

mysql_query("SELECT x, y FROM users");

And im sure limiting the amount of users that its searching for may help as well by only searching for users online too.

[Octet]

Hmmm, I like the way you're thinking KyleMassacre.

I could always incorporate it into my game by saying it should only fetch data for players within an X radius and say that they need to upgrade or whatever to be able to see enemies at a greater range.

[a_bertrand]

Octet: There is no easy way to solve the problem the way you said it. Why? Because normally you can't share a variable across multiple PHP calls / sessions. To do so you would either need to use something called shared memory (which I don't think is usable on shared hosts), or have some sort of background process which would be then called from your PHP either via named pipe or local tcp connections. The easiest way is to store the map position on a MySQL memory table, which is basically like a table but data is never stored on the disk, and act nearly as quickly as an array. Again not all shared hosts offer memory tables (for a good reason) but if your hosting does have it, it's the easiest way to implement it.

[Octet]

Octet: There is no easy way to solve the problem the way you said it. Why? Because normally you can't share a variable across multiple PHP calls / sessions. To do so you would either need to use something called shared memory (which I don't think is usable on shared hosts), or have some sort of background process which would be then called from your PHP either via named pipe or local tcp connections. The easiest way is to store the map position on a MySQL memory table, which is basically like a table but data is never stored on the disk, and act nearly as quickly as an array. Again not all shared hosts offer memory tables (for a good reason) but if your hosting does have it, it's the easiest way to implement it.

Thanks, I've never heard of memory tables before. I'm hosting it on my own server so providing I can set it up then I should be ok.

I shouldn't be sharing it across sessions though, in theory I could do it without sessions all together as I am taking it from the database. The only thing I need sessions for is to update the position of the player?

[a_bertrand]

Well how can you share the positions of the players? Think that each page load is a different process, sharing basically nothing. Variables are dropped and memory re-created every time. The trick of the sessions in PHP is basically to serialize an array in a file, and restore it on the next page load. To identify the right file a cookie is passed to the browser. Now either you do your own way to handle things across the different players, or you use what the tools offer you. I would strongly suggest to use memory tables if you can, they are both fast and works the same way as normal tables. Yet if you reboot the server the data inside the table is lot, but for a player position, I don't think it's such a huge issue.

[Octet]

Ok thanks, shall look into memory tables then.

[Spudinski]

I might have a slightly more efficient method to dealing with this..

You love JavaScript!

With things such as this, you'd ideally like to do as much as possible on the client's side.

Now, there's a few ways in which to cache/save the data to the user: localStorage, WebSQL and IndexedDB.

The support for WebSQL has officially been dropped, which is really sad, since it's much like a real database.

My favorite is localStorage, which is supported by almost every browser.

What you would do is create the entire map on the server-side once per player, and then pass the map to each client to be cached forever.

This is the basic principle is that the entire data set is replicated, and then only individual sub-sets of data is updated when it's actually changed.

To change the data is a problem point with PHP, as it's not a thread/daemon that can live forever - once a script has finished executing, it's done.

Some people turn to Node.js for this, but it is doable in PHP, but only on *nix where a daemon can be written and ran with success.

A kind of event processor will need to be created, which will asyncronously send updates to each client.

Sending the data to the client *was* a problem a few years back, since everything was always created in a "ping/pong" fashion(unless you had incredibly large amounts of resources to burn like Facebook). In HTML5 a new feature was introduced, EventSource: in short it's event's sent from the server to the client, without the client having to poll for it via some (ajax) request.

Now, the data sets are updated by the server on the backend, and only the "changed" data is sent back to the client(to reduce load, etc.). The thing here is to only send data that has changed. This will produce a sense of "live" data.

The client will then have to update their data sets individually, but that isn't your problem anymore, since it's the browsers responsibility.

A few problems I can think of:

1. Latency compensation will have to be done(something that's comparable to witchcraft).

2. The amount of work it requires, and the flawless execution it needs(you're server can't have sudden "hickups", or else clients will suffer).

3. Memory leaks, something like this will need to go through thorough testing for leaks(yes, even an 8GB super-ninja system will crash from JavaScript leaks, and I blame IE).

The benefits of this:

1. Very efficient if done right.

2. Minimal amount of resources needed for the server-side.

3. Server-side is nearly invisible to the end-user(client).

4. Server-side events are damn awesome.

Edited July 23, 2012 by Spudinski