Hello, I am currently planning on coding an online poker game with only javascript frontend, and use ajax to send updates to server, and a page like callback.html which client will open and see if there is any update it should process.
The thing is I am confused about the server part, I generally develop desktop applications and there I could create many game classes and call their functions when needed, this feels natural, but with a technology like PHP or ASP.NET how should I code it?
There are two ways in my mind, make the web pages act like a router, run a dedicated server and when client sends AJAX request to webpages, simply open a new TCP socket and push that data to actual game server. But this will basically double the request times. ( I don't know it its negligible or not )
Other way is save every game table to database and when ajax update comes to say table 5, fetch the table 5 from the database, load the data to dynamic "table" class and call the functions like normal desktop application and when everything is done save the new state of the table to database. The drawback of this is that I need to make many database queries.
So which one is a better solution do you think? Or is there a better option I couldn't think of?
Thanks.
Online poker game
Other way is save every game table to database and when ajax update comes to say table 5, fetch the table 5 from the database, load the data to dynamic "table" class and call the functions like normal desktop application and when everything is done save the new state of the table to database. The drawback of this is that I need to make many database queries.
You want active game instances to live on some server that supports long-lived HTTP requests. You can use double-buffered long-polling XHR Ajax/Ajaj requests (COMET style) or use a document with chunked transfer encoding that keeps pushing small script tags to be executed. I recommend the former :-)
The game rules should be enforced on the server, and the players need to talk to each other. Talking through a database will scale very, very poorly. Instead, you want to either use some kind of subscribing message queue, or an in-core web framework like Python/Twisted or node.js to serve game rooms.
The XHR handler will look something like:
wait (for second request to come in from same user or max 10 seconds)
wait (for data to become available or max 10 seconds)
return data
Author
Thanks for the information 
How about storing nearly everything in Application[] map? Can I adjust their lifetime if I buy a regular webhosting?(not dedicated server) or can I refresh the variables so that they are not lost?
What are the drawbacks of this method,or is it the worst thing I can do to my hosting ^^ because I know they are not created to be used like that.
I am talking about maximum 1000 concurrent users, which makes approx 200 games, 100 kb per game should be enough and that makes roughly 20 mb space. I don't have scalability in my mind, I hope I won't regret that
How about storing nearly everything in Application[] map? Can I adjust their lifetime if I buy a regular webhosting?(not dedicated server) or can I refresh the variables so that they are not lost?
What are the drawbacks of this method,or is it the worst thing I can do to my hosting ^^ because I know they are not created to be used like that.
I am talking about maximum 1000 concurrent users, which makes approx 200 games, 100 kb per game should be enough and that makes roughly 20 mb space. I don't have scalability in my mind, I hope I won't regret that
How about storing nearly everything in Application[] map? Can I adjust their lifetime if I buy a regular webhosting?(not dedicated server) or can I refresh the variables so that they are not lost?
What are the drawbacks of this method,or is it the worst thing I can do to my hosting ^^ because I know they are not created to be used like that.
I am talking about maximum 1000 concurrent users, which makes approx 200 games, 100 kb per game should be enough and that makes roughly 20 mb space. I don't have scalability in my mind, I hope I won't regret that
For any kind of gambling app, even if you don't give money out yourself, of bigger concern is regulation. If you don't already have a lawyer, discuss your project with a business lawyer before going much farther. Also you'll want to verify with your hosting company, since several major hosts forbid any form of gambling applications even if no money is involved.
For that few players a database should be fine, assuming you are smart about what you are doing.
A simple LAMP configuration can support a few thousand transactions per second.
But you can also write queries that take several seconds, or even several minutes, to complete. That is an implementation detail which you can control.
Nothing you've written pushes me toward any particular option, any persistent communications channel should be able to handle it, and the memory requirements are minimal. Then it just comes down to you being smart about what you process and transmit.
You'll still need to be careful with your design and implementation to ensure validity to avoid cheaters. That means validating all input, ensuring each client only gets the information it needs to play the game, and isn't leaked information about other player's cards, cards still in the deck, or other exploitable information.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
