I want to start a project for facebook and the application will be like real-time multiplayer chess game. The problem I'm having is I have no idea how to store the data when a player moves one piece and update the new position in player2 browser. I'm gonna use PHP, MySQL for server side and jQuery for Client Rendering. The simplest idea is to store the data in XML or MySQL and re-generate the result to player2 browser. But I know that when thousand of players are playing, it will not be an efficient way. Since I don't have time to study new language for this project, I'm gonna have to stick with PHP. I'm not going to use flash either because I want my client side light-weight and flash-free. So is there any way that will solve my problems?
you would have to be polling server for update every.. maybe 2 seconds, depends on server load. If you used flash, there would be another option - to use sockets, it's much more suitable for multiplayer games, but i don't think you could make it without some third-party runtime.. HTML5 has some kind of websockets, but it's very bad when it comes to cross-browser compatibility
I guess going through a server is your only option. That is to store the game status is xml or a sql db. And than the clients need to frequently poll this status, e.g by jquery ajax. Having the clients to communicate directly p2p is not possible with standard web components.
Related
I was just watching a ajax/php web chat client video from phpacademy (Link to the youtube videos) and I had a question about pushing and fetching. In the video they fetched the data from the MySQL database every second or so.
But my question is, is there anyway to push the chat to other connected users rather than fetching it? With the application I'm developing, It would be a lot of requests on the server and be a waste of bandwidth.
But I still want it to be as basic as the ajax/php chat system. What I'm developing is a turn base game and the idea/code behind the chat system is exactly what I'm looking for. But instead of sending a text message it might send a score, move, and/or time, etc. and having it fetch wouldn't be ideal for the server when there maybe multiple people connected.
thanks for the comments and answers.
It sounds like your after something like Socket.io, or if you cant set that up you could use http://pusher.com/
No, with php it cannot be done, as php is a server side technology.
However, you should have a look at WebRTC as it allows P2P connections and is perfect for your use case.
in javascript you may use setInterval('Messages()', 8000); for get news messages in your db EVERY 8 SECS, if this is true you show them.
I'm trying to figure out a way for users of a website (say a student and teacher) to share a secure connection where real time updates on one page are viewed by both of them.
From research I've concluded that some of the real time updates could be performed using ajax and javascript.
But I'm stumped as to how users could share a connection where only the two users would be viewing the updates that take place on the website (such as flash animations of a drawing board.) I'm also confused how you would even begin to set up a connection like this.
I've looked intp php sessions and cookies but I'm not sure I'm doing the right research.
Any pointers as to how two specific users could share a secure connection where real time updates are viewed by the both of them only. I don't want a terse response please. I'm looking for specific details like functions and syntax specific to php. I appreciate the help and will rate you up if you give me good answers!
You cannot share a secure connection (e.g. HTTPS) its one client to one server.
If both clients are logged in and have a background AJAX task running in the browser, is it acceptable to have each client "pull" every few seconds the same data to display for both users?
This would require the "drawing board" updates to also be sent continuously back to the server to share the updated data with the other client. I'm sure there will be an event you can use to trigger the post of data (e.g. on mouse up).
If performance is an issue, you'd want to use a better server technology like Java that is able to keep session state between requests without having to persist to a database.
You can look at ajax push techniques. I used comet once where an administrator posted messages and everybody who was logged in saw that message appear on their screen. I don't know if comet supports PHP. I only used it with JSP. Just search for "ajax push" in Google.
Flash allows for connections between users, I think they refer to them as sockets.
If you want to use Ajax, et al, you need a server side technology that supports push.
Node is the standard in this regard, and you can set up a Heroku instance for free.
There are others, and you need to learn tools before even beginning to learn application.
Among the many overviews, this might interest you:
http://arstechnica.com/business/2012/05/say-hello-to-the-real-real-time-web/?1
A few good examples where this is happening:
Google Docs
Etherpad
HTML5 Games: Multi player
Techniques you can use (with varying browser support)
HTML5 WebSockets (Wikipedia; MDN; HTML5 Demo)
Comet (Wikipedia)
Really pushing data to a web browser client from a server (which would do that when it receives something from another client) is only possible with WebSockets as far as I know. Other mechanism would either require browser plugins or a stand-alone application.
However with Comet (through AJAX) you can get really close to pushing data by polling the server periodically for data. However contrary to traditional polling (e.g. where a clients asks for data every 5 seconds), with the Comet principle the server will hold that periodic request hostage for, say, up to 30 seconds. The server will not send back data until either it has data or the time out is reached. That way, during those 30 seconds, any data that the server receives can be instantly pushed back to the other clients. And right after that the client starts a new 30 second session, and so forth.
Although both Comet and WebSockets should work with a PHP backend served by Apache. I'd recommend looking into NodeJS (as server technology) for this.
There is a lot of information regarding Comet on the internet, I suggest you google it, maybe start at Wikipedia.
The great thing about Comet is that it is more a principle than a technology. It uses what we already have (simple HTTP requests with AJAX), so browser support is very wide.
You could also do a combination, where you use sockets if supported and fallback to Comet.
I'm sure you have looked into this. The opinion that this can be done via ajax is misleading to believe that two users of a website can communicate via javascript.
As you are aware, javascript happens on the client and ajax is essentially 'talking to the server without a page change or refresh'.
The communication between two users of the website has to happen via the server - php and some chosen datastore.
Hope that wasn't terse.
cheers, Rob
I am trying to add the feature that Google Docs has, which is real time collaboration, to an editable textarea in HTML. For example, this would allow 2 or 3 users can edit the same textarea collaboratively. How would one go about approaching this problem, or is there is a JavaScript library that can be used? (I use PHP, mySQL, and JavaScript/AJAX/jQuery).
In order to facilitate real-time updates between more than one Web client, you'll need to use a technology that either capitalizes on the request/response cycle of the Web by using a Comet or Websockets solution.
To keep the textarea updated, you'd need to establish a long-lived HTTP connection or a Websocket connection to your server from all 3 clients. Each textarea would need a keyup or keypress handler that, when invoked, sends the character across the stream to the server. When your server retrieves this data, it would then need to return a response to the other 2 connected clients.
The response would need to then be handled by updating the value property of the textarea with the most recent data.
I see you're using PHP, which I do know supports comet. You'll need to setup comet (or Websockets) in order to implement such a solution.
With that said, a more rudimentary alternative would be to use polling to achieve the desired effect. This would involve all 3 clients making requests to the server periodically to retrieve updates. As you can imagine, the faster the polling rate, the more real time the application would feel. However, with a faster the polling rate, your application would consume more bandwidth and resources.
For 3 clients, this may be feasible, but for any serious application that involved heavy usage, you would definitely want to look into Websockets or Comet.
To answer your question of JavaScript libraries, check out the Dojo Cometd library for a Comet solution on the client-side.
I would like to create a chess multiplayer game,1player vs 1player .
I will use flash for animations and client and a server-side language for checking if the moves are correct, record each player action to a database, decide winner and give some credits to the winner.
My main programming language is PHP and I will have someone do the flash work depending on my directions.
I would like to know if anybody tried to do this before , or if you have any tutorial, guide, steps to follow when developing p2p games ? I want to do this efficiently and to be able to support up to at least 100 players on a VDS with 512 RAM .
I am planning to have the game work like this :
1) Initialise variables like credits, player names inside the flash client , after retrieving them from php
2) Start the game
3) If I am player2 and player1 is thinking of a decision, the flash client will send requests to the PHP file to check the database if player1 made any decision. If so, it will be my turn to do a decision and move a piece
4) When my turn comes , no requests are sent to the PHP anymore, until I want to move a piece . When I try to do that ,it sends a request and the PHP will check if my move is valid, and return some variables that flash will use to show error or move pointer back to player1
The game will also have a timer that will sync with PHP. Each player can think 20 seconds to do a move.
1)Any suggestions for my implementation ?What im looking for are suggestions to improve efficiency on this and reduce server load and if someone ever had any experience with a similar project, how did they do it, or how would they do it ?
2)My implementation of periodical HTTP requests isnt such a good idea, because I know that the server can become overloaded, I'd like to know if someone can suggest any alternative but secure option . 100 users at the same time would mean about 100 HTTP requests/second. Is that a number that a VDS can handle for days ?
Later Edit :
After the replies that I got on this post , I came to the conclusion that using sockets instead of HTTP requests every second would be the best idea to use when waiting for a move on the opposite player.
My game would have 100 tables available for players, with 1 socket for communication and 1 port for each table . So 1 socket with 100 ports. PHP will communicate to flash the socket and port for the table , when the game starts and the initialisation variables are sent.
I plan to use flash to listen to the socket server and see what happens when the opposite player must move .
When I move , flash will check if the move is valid from it's side, then send data to PHP . PHP will return OK or NOT and will also update the data on the socket port.
About the socket , Im not sure javascript would be a good option for this, so Im thinking about PHP sockets or JAVA sockets.
PHP sockets seem to be my first option , due to familiarity with the language.
My 2nd would be to rent a smartfoxserver and my 3rd would be to use the services of Player.IO.
Im planing to create a very nice game and sell it. The graphics are pretty much done and they look great. The hardest part is doing this efficiently and easy to install after.
Thank you for your time ! Regards
The server load for a game like this should be really minimal. If you're using flash, I would take advantage of the socket object and just open a socket to your server, that way you don't need to pester it with questions about what has changed... it will notify the clients when/if something noteworthy has.
Otherwise your plan is a pretty good one, so, you'll probably have to ask some specific questions about things that you're stumped by.
If you REALLY want to reduce server load, write the chess logic in the flash client and let IT decide if an attempted move (by the player) is illegal, or if the player has lost or whatnot... use the server strictly for message relay and data storage.
It's sometimes a mistake to design a project around what you have available, such as PHP knowledge and access to a server with 512 MB of RAM. There are a lot of projects where you should consider your resources first, but an independent, first time game project isn't one of them.
Even though your primary language is PHP, you shouldn't restrict yourself from working on the Flash portion yourself. Also, using a web server and database as a communication method for a multiplayer game will result in some very clunky behavior.
You aren't limited by your VDS either. You can use a micro instance on Amazon EC2 for free for a year. If setting up an EC2 server from scratch seems daunting, there are tutorials all over the internet that take you from start to finish.
The front end of your game can be written in Javascript or Flash AS3. There are a lot of game development libraries available for both. Flixel, Flashpunk, and PushButton are free AS3 game libraries. MelonJS is a Javascript/HTML5 game library. All of them have extensive documentation and a good community.
You can write the server backend using node.js and use socket.io to handle your game communications, even if you don't know anything about packets -- or you could use something like Player.IO if you want to pay a little money and have an outside service worry about that for you.
If you write the backend properly, one hundred users won't be a problem for your server. You'll need to start thinking about new hardware when you get in the thousands.
And since you're looking for general game making advice, start reading articles on blogs like #AltDevBlogADay. You'll pick up a lot of insight on design from other people passionate about games.
Would it be safe to use a MySQL database to record positions of players on the screen?
Then everyone second, Flash retrieves the new position data in the database and sets the players' positions of the map to the new positions?
I'm not sure how slow this would be.
I know PHP.
I know SQL.
I am not very experienced in ActionScript, but I can do basic things like set positions of objects.
I do not know how to retrieve information from a database via Flash.
I do not know how to make Flash send out queries.
Do you think you could give me a bit of help?
It would be safe to use MySQL.
But, I strongly wouldn't recommend using PHP + MySQL as a game server though, or your server will tend to lock up from the influx of requests. The HTTP protocol was not designed for this.
It might take a bit of time, but I would learn an easy programming language (especially something like Java or C#) to create a basic server. Then you can store their user information within RAM, instead of constantly accessing the database repeatedly. But, you could also have it where the server updates a database every n amount of minutes, in case the server is shutdown and needs to be started back up with the same data.
Look up 'Flash Remoting' for flash<->server communications. An open-source server-side handler for that is AMFPHP. Flash would send out AMF messages, AMFPHP translates that back into normal PHP data structures, and then you'd have the PHP code handle interfacing to the database.
you would have php be a controller between your db and flash. So flash would send/receive info from php and php would query db.
Yeah, MySQL is pretty secure, as long as you strip all tags, mysql injection etc from the string. And it should be pretty instant.
However, hundreds of MySQL requests every second will be a lot of bandwidth, although I can't think of any alternatives.