Design question server side programming in php_问答_开发者

I am trying to write a multiplayer game similar to say Go and was wondering how people do the communication across players on the server side?

Since there is nothing in php (or any other language) to do this I could write every move to a DB and read it for the other player(s). But this seems so wasteful for the following reasons -

I don't need to store the moves of various players. (unless you convince me that this is absolutely necessary)
The DB will be write heavy as well as read heavy ( a lot of resources I can use for something else)
Its ok to store things in memory for now. I am looking to quickly prototype this. (I understand that if I store things in memory I lose the whole game for all users if the machine instant dies).

So even though its a different use case what do in-browser chat applications do? There is a definite case for me to write to a DB since its a game that could last upto 10-15 mins but for a chat its definitely not needed.

Any ot开发者_Go百科her software I should be aware of? Can I use an XMPP server (have not looked into this yet) but does it work with regular standard HTTP post/get?

Point me some URLs and I will do the research from there. Thanks for your help.

I'd advocate XMPP pretty much because it solves most of the issues for you. Most XMPP servers do support connecting via HTTP (via a COMET-like technique known as BOSH), there are at least two pure-Javascript libraries that allow that directly from the browser: Strophe.js and JSJaC

Typically because of the short routing times an XMPP server keeps messages in memory only, so doesn't write them to a database. Most servers support plugins so that changing the system to e.g. record moves or store messages to a database transparently would be possible later on.

One of the Strophe.js authors wrote a book that has a chapter on writing a simple two-player game (actually Tic-Tac-Toe), so you might want to check that out if you go down this route.

I've used Memcached to do this kind of thing. It's very fast and doesn't store all of the moves (just overwrite the players' keys). It'll make things nice and easy for you.

There are two PHP Memcached libraries in PECL (Memecache and Memcached). Both do the job just fine.

Many chats use flat-files. Flat files might be the right choice for you too. As might some unorthodox uses of Memcached. Games are transitory in nature. So doing the same things PHP does for Session might be a good way to pattern your system.

Good luck!

I have never heard about that game, but for example a web game like Ogame uses database to store movements and stuff. Others use flat file but that seems not great to me since I heard a lot about safety issues. It's sure that a well designed database application is way much safer than any other tools. The real problem is another: php is not made for game and probably never will.

If HTML 5 were up and running, you would want to use a socket connection to your server for this (You can currently do this with Flash already). Basically, you would have a daemon script running on your server at all times, that would listen on a certain socket, and keep a list of connected users, then when a message is sent to the socket server from one of the connected users, the socket server would parse the message, and forward it to the correct connected users. This way nothing too large needs to be stored in memory. It would receive and immediately send back out the messages.

The client would basically create a persistent connection to the socket server, and have a handler to receive messages sent back by the server daemon. Server daemons can be PHP run via command line (so that it is always running and does not time out). You would want to make an init shell script for your server that runs the PHP daemon script on boot up. You would also need access to sockets from your PHP script (which is not allowed on most shared servers), meaning you would probably need a VPS (virtual private server).

This is the sort of thing that HTML5 will bring us towards, but your best but for now is using Flash instead (or use one of the less efficient methods that is not truly asynchronous). This is a large subject to get in to so I cannot go into too much detail, but I can at least point you in the right direction. There are probably examples of this somewhere on the internet.