I want to build a TCG for mobile devices that is multiplayer over the web (not local wifi or bluetooth). As a player plays cards I want the second player to see what is being played in "real time" (within a few seconds). Only one player can play at a time.

Server requirements:
1) Continuously listens for input from Player 1
2) As it receives input from Player 1, sends the message to Player 2

I know some PHP, but it seems like unless I had a loop that continued until I broke it (seems like a bad idea) the script would just receive one input and quit.

On the mobile side I know I can open sockets using various frameworks, but what language allows a "stream-like" behavior that continuously listens/sends messages on the server?

Or if I'm missing something, what would be the best practice here?

EDIT: I might have not made it clear before, but the mobile apps are native not web-based.

I guess I'm asking for specific suggestions on what some of the best tools or platforms for this scenario could be used i.e., PHP sockets, etc.

  • \$\begingroup\$ What did you already tried and didn't work? You don't need sockets for this, "Comet" technology would be enough. \$\endgroup\$ Oct 7, 2012 at 6:59
  • \$\begingroup\$ possible duplicate of Is there a pattern for writing a turn-based server communicating with n clients over sockets? \$\endgroup\$
    – House
    Oct 7, 2012 at 7:07
  • \$\begingroup\$ If you already know PHP, you could use Javascript to refresh the cards every 'x' seconds, it's quite simple. \$\endgroup\$ Oct 7, 2012 at 10:32
  • \$\begingroup\$ @JonathanConnell Javascript to refresh the script? I might be misunderstanding you but the mobile apps are native iOS/Android, not webviews. \$\endgroup\$
    – jmosesman
    Oct 7, 2012 at 17:04
  • \$\begingroup\$ @Byte56 I think it's rather a duplicate of this question. jmosesman: it doesn't really matter if your client is JavaScript or a native App. You could easily do this using http requests with a PHP backend (just make sure you make the game-state persistent after each request)... \$\endgroup\$
    – bummzack
    Oct 7, 2012 at 18:43

2 Answers 2


If you want to use sockets, you should probably choose a different language, perhaps Python or Node.js (server-side JavaScript); PHP is best suited for generating HTML in response to requests. Sockets would be used for truly real-time data, but PHP would be adequate for data that can be a few seconds delayed; you would just need to have the client keep polling the PHP page for updates.

We have a number of questions already covering making multiplayer games with PHP. Try searching for PHP multiplayer and looking through those questions & answers.

The only difference in your case is that you want a mobile app as the client. For a native app, just have the app make a background HTTP request to the PHP page, then parse the data that comes back. Do this repeatedly, as frequently as you need. Your PHP page would probably respond in a computer-readable format, so research REST, JSON, and SOAP.

Or you could just make the webpage that the PHP generates mobile-device-friendly, perhaps using something like PhoneGap to have an actual app (and also take advantage of device features like GPS if you need them).

As for the actual PHP page(s), my recommendation would be to just have them poll a database, and use the database to store the state of the game. Timestamp everything, the first login request responds with the current state, and then each update request from the client should include the client's last update timestamp, and the PHP page should just gather the data from the database that's newer than the client timestamp and send it back, along with the new timestamp.

And of course, when the client performs an action, just store it in the database with the timestamp.

  • \$\begingroup\$ Thank you for your answer! I thought about just firing off URL connections repeatedly until the database has new information, but it sounded like it would be inefficient. But that seems to be what you're suggesting. \$\endgroup\$
    – jmosesman
    Oct 7, 2012 at 19:03
  • \$\begingroup\$ @jmosesman if you mean http requests, then again, google "comet" technology. It's so-called "long-polling", even though you're using http requests, server can notify you without polling every 5s. \$\endgroup\$ Oct 7, 2012 at 19:38
  • \$\begingroup\$ @MarkusvonBroady I think I'm starting to understand it. So I can use the sleep function to wait on the server side, so my connection from the device just hangs open until the server returns something? \$\endgroup\$
    – jmosesman
    Oct 8, 2012 at 0:23
  • \$\begingroup\$ @jmosesman Yes, and then just before the timeout (enforced by your web server, e.g. Apache), exit() the PHP script and have the client open a new connection. \$\endgroup\$
    – Ricket
    Oct 8, 2012 at 1:55
  • \$\begingroup\$ @Ricket Ok. How can I set the timeout or know when it will happen? \$\endgroup\$
    – jmosesman
    Oct 8, 2012 at 5:03

You should go for a Real-Time Web server, allowing you to achieve full-duplex bi-directional communication between each client and the server. One of the most mature Real-Time Web servers is Lightstreamer (of which I am the CTO). It includes client-side APIs for all the platforms. On the server side, you can implement your own Data Adapter to inject your logic.

Check it out at http://www.lightstreamer.com


You must log in to answer this question.

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