Using sockets for real-time communication, the idea would be something like the following:
The server is listening; players A and B have connected to it.
Player A drags an element onscreen; a dragging message is sent to the server, with the details of the drag.
- The server receives the drag message and sends it on to player B, wrapping it with player A's name.
- Player B receives the drag message and sees that it's from player A. It gets the data from the message and uses it to update player A's representation on screen.
A good start would be Oracle's official lesson, "All About Sockets".
This is possible with PHP & MySQL, but the flow is much different; it requires repeated polling for updates (or a trick like Comet; which is still polling, just less frequently).
Your database would have the typical data; a table for
Players, a table maybe for
PlayerDrawnObjects... (you should probably choose better names). But it should have one more table, let's call it
Actions. Your flow would now be like this:
- Player A "connects" by requesting the PHP page; the PHP page gives it the information of the player drawn objects and the currently logged on players. It also gives a timestamp value, which is the current time on the server (time()), and which player A's client saves in a variable. The
Players record for Player A is updated to set the "LoggedIn" column to TRUE. In addition, the PHP page adds a record to the
Actions table which says that Player A logged in, and that record is timestamped with the current
- Player B does the same.
- It's been a couple seconds since Player A got the initial state of the game, so his client decides it's time to update. The PHP page is requested again, this time sending along the timestamp that was given to it and asking for an update rather than a "connection". The PHP script does a
select on the MySQL server, of all the records in the
Actions table where the timestamp is newer than the given timestamp; i.e., all the records saved in the past couple seconds. This would include the Player B login event. It returns back those records (player B's login event), along with a new
time(). Player A's client now updates to show player B, and that time variable is updated.
- This is repeated every few seconds by every player; or in the case of Comet, every player has requested the PHP page and the PHP page is looping, waiting for a new entry in the Actions table to send back to the client. Either way, the essence is that the client holds a timestamp (given by the server) of the last update it received, it keeps passing it back to the server and receiving new records and updating its timestamp, and this is how things stay current.
- Every action needs to be updated both as a line in the
Actions table, and as a change in the permanent database schema. Because remember, when a new player logs in, it pulls data from other tables besides the
Actions table; the
Actions table is for players who already "connected". You certainly could just use the
Actions table, but then every new player would have to "catch up" by reading all of the actions and fast-forwarding through them, and that would be a lot of extra bandwidth. (a hybrid solution could be designed if you're adventurous...)
- Alright, so Player A drags. His client requests a different PHP page, which inserts a record into the
Actions table explaining the drag operation, and updates the
position data for the object in the
- On the next poll, Player B receives that new record in the
Actions table and updates the on-screen representation of the object accordingly.
Sockets are truly real-time; messages are pushed across the wire and received very quickly. Comet can make PHP more real-time, but it's still a more complicated process to use MySQL as shared storage for message-passing.
I personally implemented the second method some years ago, when I didn't have access to run a server but had a shared web host which supported PHP. Nowadays, I would probably use the first method, writing a custom server and hosting it on a VPS or some other server I had access to; perhaps even a "cloud application" service like Heroku.