I am building a poker game via html/php/ajax (and some other stuff) NO-FLASH .
I have little experience in programming games , so i have small question !
assuming ur playing poker , how your browser will know that some player threw a card ?
shall my browser send ajax request to know if somebody made a move ??? or is there anyway to treat ajax->php like a socket ajax<->php ??
I hope someone understands my question , thanks
Depending on the amount of traffic you'll, face, a good idea is to use a Message Queue server, such as Apache ActiveMQ along with something to allow all browsers to connect to ActiveMQ and receive 'push' messages from it, on the lines of Orbited 2 - this one is prepared for changes on the websocket protocol as new reviews are generated (not sure a consensus over the protocol has been reached yet).
The best bet for you is to research a relatively old technology, but not widely used (I mean, when compared to Ajax) that is known both as Comet and Ajax Push.
It's obvious there are several other implementations, such as APE, and you would probably want to pick the one (whose programming language and/or API) you feel mostly comfortable with.
Related
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 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.
Again, to re-iterate: This is not a request to program anything for me. I am looking for more experienced web developers to tell me if my idea is really doable, as it involves some pretty tough issues (at least, I think so). Please, if this post is to be closed, could I at least get a little advice on where I should be posting instead first?
Imagine: You visit a website (say malonssite.com). You sign in, you get a double-paned window. Left side is chat list(think FB buddy list). Right side is a "browser".
The chat list is populated by other people who have signed into malonssite.com AND are visiting the same page as as you using the "embedded" browser.
Each user has the ability to "allow followers", at which point whatever site they visit, all their followers "follow".
Image sketch:
My abilities:
PHP
MySQL
Javascript (node.js included, but that's more serverish I guess)
I've done long polling and ajax, but this gets complicated. I am thinking something like this might be best done in flash? Or maybe an oldschool Java applet? I am just not sure.
I am pretty confident I can make this thing on my own, I am just not sure what technology to use. I usually hit stumbling blocks in each area, normally along the lines of the same origin policy. I know that JSONP can get around the SOP, however is it powerful enough to do what I want? I am not familiar enough with it.
Sockets in general (websockets, flash sockets, etc) and node.js are pretty new to me, and I think they somehow hold the answer, I am just looking for some verification.
Thanks!
As I see it, you'll just need an iframe with a JScript asking its src and sending it to the server. So basically the user will stay on your own domain, browsing other web sites in the iframe and you will have no cross-origin-request issues.
You could use ape engine for the server side, which is exactly meant for this sort of things.
It is very possible.
Simple? no. But possible.
HTML/CSS/JS will easily take care of the front end layout,that should be elementary.
Node.js is a good option, and would be best suited if you know that traffic will be heavy.
If traffic won't be heavy, i guess php is OK.
And you will also need a backend database...again, depends on how many users you think you'll have. nosql ones would suit well, although oracle just claimed they 'exponentially' improved mySQL performance.
But think about this idea carefully. The concept of allowing users to communicate if they're on the same page is neat - but they'd have to browse a site within your site....furthermore, you have to account when the user presses next/back button in the browser.
perhaps you could make a fork of firefox and implement this as a software
did you mean something like talkita
or any other solution on google search "chat with others on same page"?
some of them also allow followors (subscribers) etc..
have a look, maybe youll get an idea.
please forget about flash and java applets...
i think this is a great idea and i hope you can get it to work.
I would really use NodeJS + (Socket.IO | SockJS) for the server-side and realtime communication, all your SOP problems will be gone.
As for the client side, just take care of cross browsing the javascript and css
For data persistence, some kind of nosql implementation: mongoDB or couchDB for example
I'd like to create an application where when a Super user clicks a link the users should get a notification or rather a content like a pdf for them to access on the screen.
Use Case: When a teacher wants to share a PDF with his students he should be able to notify his students about the pdf available for download and a link has to be provided to do the same.
There are several ways you can accomplish this. The most supported way is through a technique called Comet or long-polling. Basically, the client sends a request to the server and the server doesn't send a response until some event happens. This gives the illusion that the server is pushing to the client.
There are other methods and technologies that actually allow pushing to the client instead of just simulating it (i.e. Web Sockets), but many browsers don't support them.
As you want to implement this in CakePHP (so I assume it's a web-based application), the user will have to have an 'active' page open in order to receive the push messages.
It's worth looking at the first two answers to this, but also just think about how other sites might achieve this. Sites like Facebook, BBC, Stackoverflow all use techniques to keep pages up to date.
I suspect Facebook just uses some AJAX that runs in a loop/timer to periodically pull updates in a way that would make it look like push. If the update request is often enough (short time period), it'll almost look realtime. If it's a long time period it'll look like a pull. Finding the right balance between up-to-dateness and browser/processor/network thrashing is the key.
The actual request shouldn't thrash the system, but the reply in some applications may be much bigger. In your case, the data in each direction is tiny, so you could make the request loop quite short.
Experiment!
Standard HTTP protocol doesn't allow push from server to client. You can emulate this by using for example AJAX requests with small interval.
Have a look at php-amqplib and RabbitMQ. Together they can help you implement AMQP (Advanced Message Queuing Protocol). Essentially your web page can be made to update by pushing a message to it.
[EDIT] I recently came across Pusher which I have implemented for a project. It is a HTML5 WebSocket powered realtime messaging service. It works really well and has a free bottom tier plan. It's also extremely simple to implement.
Check out node.js in combination with socket.io and express. Great starting point here
What way will be best to write online chat with js? If i would use AJAX and update information about users and messages every 5sec - HTTP requests and answers will make big traffic and requests will make high server load.
But how another? Sockets? But how..
You seem to have a problem with the server load, so I'll compare the relevant technologies.
Ajax polling:
This is the most straightforward. You do setTimeout loop every 5 seconds or so often to check for new chat messages or you set an iframe to reload. When you post a message, you also return new messages, and things shouldn't get out of order. The biggest drawback with this method is that you're unlikely to poll with a frequency corresponding to how often messages are posted. Either you'll poll too quickly, and you'll make a lot of extra requests, or you'll poll too slowly and you'll get chunks of messages at a time instead of getting them in a real-time-ish way. This is by far the easiest method though.
HTTP Push
This is the idea that the server should tell the client when there are new messages, rather than the client continually bothering the server asking if there are any new ones yet. Imagine the parent driving and kid asking "are we there yet?", you can just have the parent tell the kid when they get there.
There are a couple ways to both fake this and do it for real. WebSockets, which you mentioned, are actually creating a stream between the client and the server and sending data in real time. This is awesome, and for the 4 out of 10 users that have a browser that can do it, they'll be pretty psyched. Everyone else will have a broken page. Sorry. Maybe in a couple years.
You can also fake push tech with things like long-polling. The idea is that you ask the server if there are any new messages, and the server doesn't answer until a new message has appeared or some preset limit (30 seconds or so) has been reached. This keeps the number of requests to a minimum, while using known web technologies, so most browsers will work with it. You'll have a high connection concurrency, but they really aren't doing anything, so it should have too high a server cost.
I've used all of these before, but ended up going with long polling myself. You can find out more about how to actually do it here: How do I implement basic "Long Polling"?
You should chose sockets rather than AJAX Polling, However there isn't much around about how you can integrate socket based chats with MySQL.
I have done a few tests and have a basic example working here: https://github.com/andrefigueira/PHP-MySQL-Sockets-Chat
It makes use of Ratchet (http://socketo.me/) for the creation of the chat server in PHP.
And you can send chat messages to the DB by sending the server JSON with the information of who is chatting, (if of course you have user sessions)
There are a few ways that give the messages to the client immediately:
HTML5 Websockets
good because you can use them like real sockets
bad because only a few browsers support it
Endlessly-loading frame
good because every browser supports it
not so cool because you have to do AJAX requests for sending stuff
you can send commands to the client by embedding <script> tags in the content
the script gets executed immediately, too!
...
So, in conclusion, I would choose the second way.
The typical approach is to use long polling. Though better not do this in PHP (PHP will need one process for each connection thus drastically limiting the number of possible visitors to your site). Instead use node.js. It's perfect for chats.