Turn based browser concept?

Started by
4 comments, last by hplus0603 13 years ago
How would userA and userB be able to communicate with each other through a browser style turn based game?

Would each users 'client' have to poll the database to see if some value has been reached, then 'refresh', or is there a way to directly send data to a user without the user initiating the data transfer?

I was planning on using php and MySQL. For an example, userA chooses card[3] and attacks userB card[6]. How do I send this update to both users at the same time? The one initiating the attack is easy, I could use a post response. But how would I send this information to userB?

Would the session ID work? Or something like that?
Advertisement
Hi,

With simple webpages (i.e. without any add-ons/plugins), there isn't a way the server could send data to the client browser without the browser initiating a request.

One solution is to use the meta refresh tag to automatically refresh the page every few seconds to see the current state of the game - This is quite simple to implement, but it is extremely irritating to use.

EDIT: Here is an example of a two-payer tic tac toe game implemented with the meta refresh tags: http://www.15seconds.com/issue/990203.htm
It is programmed in ASP, but it does explain the method of auto refreshing, and also some important tips for protection from malicious users and for handling a user which exits the game without notifying the server

Another solution is to use Ajax to dynamically changing parts of the page - This is a more complicated solution and you might need to program some JavaScript, but it is much more user friendly and elegent.

Good luck,
sss_1234
------------------------Computers do what you tell them to do, not what you want them to do.
Yea, I might use a flag system along with a 'poll' every 3 seconds or so.

every 3 seconds, send 'request_change'.

Then if the different users choose things like 'ready' or 'leave' etc, I can use a flag system... 1=ready 2=whatever, 4=whatever, 8=...

Then on the post response, I can just send data about the delta change things, rather than the entire 'page'.

if(change &1){get new 'ready' state value)
if(change &2){get ...}
if(change &4){get ...}

Then send flags + data to the client.

Sort of like a delta change + poll system.

How would userA and userB be able to communicate with each other through a browser style turn based game?

Would each users 'client' have to poll the database to see if some value has been reached, then 'refresh', or is there a way to directly send data to a user without the user initiating the data transfer?

I was planning on using php and MySQL. For an example, userA chooses card[3] and attacks userB card[6]. How do I send this update to both users at the same time? The one initiating the attack is easy, I could use a post response. But how would I send this information to userB?

Would the session ID work? Or something like that?


What you want to google for is "comet" because of the "periodically return" behavior of the typical implementation.
This means that there exists a queue on the server side for messages to a particular session or user.
The user will make a XMLHttpRequest (or JSONP script request) to retrieve the queued data. If there is no data, this request will "hang" until there is data or some timeout expires on the server side.
For a really high performance comet implementation, you want two XHR from the client. When the second one comes in, the first one returns with whatever data is available, and the second one blocks, waiting for the first to come in. This allows you to double-buffer at whatever rate the connection between the clients can sustain. With HTTP/1.1 keep-alive, this is less inefficient than it may initially sounds.
enum Bool { True, False, FileNotFound };
Bah, I think I'll just run a server that houses the database locally.

I started to make some progress with php+mysql, but there is just so much I don't know how to do. I guess it would be a good learning experience.

For example, I thought to create a buffer for room actions, like messages sent, client input, etc. Then on the 'poll' I would only send the delta change in the room since the last update poll.

But I don't know php very well, or MySQL for that matter, to handle such an idea.

For example, an 'action' could be something like username sent a text message. Or it could be, username left the lobby. Username joined the lobby.

For in game stuff... username clicked ready button, username attacking card[4] with card[7], and has consumable card[77] and consumable card[21].

Hmmm... any suggestions?

But I don't know php very well, or MySQL for that matter, to handle such an idea.


So to solve that problem, you're doing... what?

Note that PHP/MySQL is not a great choice for a COMET style web app, because it has no persistent process, and thus you have to scrape state out of the database for each request. That will not scale very well.
A better option might be a node.js process with state for each game that's running. Once you exceed the capacity of a single machine (which will take a while when using node -- it's very efficient!) you can scale by sharding game instances across machines and routing requests based on what game instance they're asking for.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement