I'm developing a simple multi-player puzzle game in Java. Both players should be able to view the same game board on his own computer. Then, when one player makes an action in the game (ex. drags an object onto a coordinate space), the game's view should update automatically on the other computer's game screen. I'd like all this to happen over the internet, not requiring both computers to be on the same LAN connection.

If I need to use SQL/PHP to accomplish this, I'm unsure how to design the database to accomplish something as simple as the following:

Player A drags element onscreen
Game sends coordinates of element to database/server

Player B's computer detects a change to an item in the database
Player B's computer grabs the coordinates of Player A's item
Player B's machine draws onscreen elements at the received coordinates

Could somebody point me in the right direction?

  • \$\begingroup\$ Is this a web based game? \$\endgroup\$ Commented Oct 10, 2012 at 21:09
  • \$\begingroup\$ I had planned on it simply being a window-based Java program. \$\endgroup\$
    – The Kraken
    Commented Oct 10, 2012 at 21:51
  • \$\begingroup\$ The reason I ask is because PHP is normally used as a web server side language to generate dynamic web pages. If you just want to create a networked game, you really don't need databases. The server is just another version of your game that reads input from clients and sends output to clients in real time \$\endgroup\$ Commented Oct 10, 2012 at 22:23
  • \$\begingroup\$ Okay, that make sense. So in Java, how do I communicate with the server version of my game from the client side? \$\endgroup\$
    – The Kraken
    Commented Oct 10, 2012 at 22:41
  • \$\begingroup\$ This is a good series on networking in games: gafferongames.com/networking-for-game-programmers \$\endgroup\$ Commented Oct 10, 2012 at 23:03

2 Answers 2


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 time().
  • 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 PlayerDrawnObjects table.
  • 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.

  • \$\begingroup\$ It's important that the connection be very fast so that both game boards are in sync. Do you think that the PHP method will be fast enough? \$\endgroup\$
    – The Kraken
    Commented Oct 11, 2012 at 1:51
  • 1
    \$\begingroup\$ Well, I don't know what "very fast" is, and it really depends on the client's connections, the server speed, etc... The only real way to test it is to actually test it. Make a small test client and server that just automatically send messages and time how long it takes, or something. Also, gracefully handle when the boards are out of sync, because the nature of the internet is that sometimes things will lag a bit. If they absolutely need to be in sync, then consider using some sort of lock step method to enforce that they're in sync, at the cost of UI responsiveness. \$\endgroup\$
    – Ricket
    Commented Oct 11, 2012 at 3:48

You can either do direct socket connection between the two computers, or you can mediate the connection with php/sql.

In the client it would propagate moves to the server would store it in the database, on the other end the user would poll the web service to detect any pending changes and update on their end.

The database should probably just be a list of moves and whether they have been delivered.

The idea being that if you exchange the list of moves you can recreate an identical state on both ends.

Be aware though, you would need to "push" the updates if you wanted them to propagate near realtime and this is not something that web-servers do. Web servers respond to request, they don't force anyone to consume anything they didn't ask for.

So you might want direct socket communication so that you can directly communicate between clients with lower latency. You can maybe use a website/php/database to help with matchmaking which would be a more appropriate use of a website.

  • \$\begingroup\$ Okay, makes sense. But communicating over sockets would require both computers to be on the same network, correct? \$\endgroup\$
    – The Kraken
    Commented Oct 11, 2012 at 0:20
  • \$\begingroup\$ If by Internet, than yes. You can have a socket2socket connection between two computers, given they are accessible over the network. If the networks are nat'd you can often use uPnP to establish a direct connection between the devices. \$\endgroup\$
    – HaMMeReD
    Commented Oct 11, 2012 at 0:28
  • \$\begingroup\$ There is also the "Skype" method which punches through firewalls and allows direct p2p via "punching". You use a server to help initiate the direct connection between clients. Some info here. h-online.com/security/features/… \$\endgroup\$
    – HaMMeReD
    Commented Oct 11, 2012 at 0:32
  • 2
    \$\begingroup\$ @TheKraken Sockets allow communication over networks, and the internet is a really big network. When you loaded this webpage, you did so over a TCP socket between your computer and the gamedev.stackexchange.com server. \$\endgroup\$
    – Ricket
    Commented Oct 11, 2012 at 3:50

You must log in to answer this question.

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