Page 1 of 1
PHP Gaming basics
Posted: Tue Dec 02, 2008 9:59 pm
by JRiga
I am trying to develop a game using PHP, where one server communicates to two separate clients for the same game. I don't understand the mechanism that allows the server to do this. I am a professional programmer with 40 years experience, but am a bit weak with this type of gaming. I have developed a Javascript version of the game on
http://www.dynodice.com , but need help on the PHP version, because of the extra communication requirements. Any suggestions?
Re: PHP Gaming basics
Posted: Tue Dec 02, 2008 10:09 pm
by alex.barylski
. I don't understand the mechanism that allows the server to do this.
Not PHP, per se.
am a professional programmer with 40 years experience, but am a bit weak with this type of gaming
In 40 years you never learned about protocols?

It's possible I suppose...but jesus...were you stuck in a dark room developing QBASIC the whole time?
have developed a Javascript version of the game on
http://www.dynodice.com , but need help on the PHP version, because of the extra communication requirements. Any suggestions
Your clients user-agents (ie: browser) would have to perdiodically check the server for updates (using AJAX or similar) and update their screen appropriately. Alternatively you could use Flash or a Java/ActiveX applet.
Cheers,
Alex
Re: PHP Gaming basics
Posted: Wed Dec 03, 2008 7:39 pm
by JRiga
Thanks for the advice. This was the type of direction I needed.
Re: PHP Gaming basics
Posted: Wed Dec 03, 2008 11:02 pm
by josh
What you are referring to is called a two tier architecture it would seem, UI is the client tier, which talks to the application tier. Protocol for communication will probably be http, the most widely used techniques to look into are using SOAP, or raw JSON / XML. All information is validated and persisted on the application tier of course, keeping the UI tier as simple as possible, which will also help you roll out additional versions of the UI tier to make the application more platform portable. Depending on complexity of this communication you might need some middle ware architecture, like event notification channels, priority queues, etc... ( offline delivery, dropped connection handling, etc.. )
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 1:04 pm
by crazycoders
PCSpectra wrote:In 40 years you never learned about protocols?

It's possible I suppose...but jesus...were you stuck in a dark room developing QBASIC the whole time?
Ohhh you'd be surprised as to how many developpers don't bother looking under the hood... If they have an object interface and they call Web.Get("
Http://something.com/") and it works, it's not their problem as to how it works... It just works...
I have worked with 3 people like that. One 65 years old programmer (About 40 years exp) and asked him how he'd program a socket... he looked puzzled and asked me what was a socket... shocked was I!
The other most noticable is a programmer with about 10 years of experience and for him... AJAX is simply to write JS code in the output buffer... Because his breakpoint would fire in his ASP.Net page twice (Once cause he called it and once because he put the equivalent of <?php echo Myfunction("OutputAsJs"); ?> in his code, it meant it was called as AJAX... O_o
JRiga wrote:I am trying to develop a game using PHP, where one server communicates to two separate clients for the same game. I don't understand the mechanism that allows the server to do this.
To anwser your question JRiga, it really depends on how you wish your players to communicate. First understand that the web (php, asp, perl, etc) are all request based... no connection is held between the client and the server per se... What you have at your disposal though are mechanism to requery for more information either in the form of posting back a query through conventionnal means of a form or a link. (Lots of games on FaceBook are built that way)
Another way would be to use AJAX style constructs and use an AJAX library to call your web server for more information or to execute operations. The call could be a posting of an action or a retrieve of a chat log for example.
Finaly, note that the server itself cannot communicate to a client because nothing on the client side is listening for incoming connections unless you have some kind of server in the form of a pluggin that listens to that but let me tell you that this practice is NOT recommended due to security issues.
The way you display your game information and interact between users is usually database driven. A user posts and action and it is stored into the game server. Then the result is sent back to the user. That mechanism can be implemented using FLASH, Javascript/AJAX or any other similar technology but it is always the client that sends information to the server and the server responds with the new state information. The client then processes the information and shows it to the client through the previous means (flash or html)...
I hope i was clear and that i didn't bust your bubble too much. If you need help, contact me directly, i have built a good deal of games on the web so far, not a lot, but i have a total of 3 good games i was able to build and one is still online on FaceBook.
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 1:23 pm
by Eran
Flash would definitely be a much more capable platform for game development than PHP / JS. If you're feeling frisky, I'd also give the canvas element a shot, it can do very nice things (though it won't be very portable).
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 3:11 pm
by josh
Flash still needs backed technology to communicate with ( if you're doing a 2 tiered architecture, which is almost implicit nowadays.. games like world of warcraft, etc.. all implement client->server ). Zend just realeased adobe afm for flash / flex.
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 3:23 pm
by Eran
Not all games need persistence (those are flash games we are talking here, not WoW). My recent favorite is such a game -
http://www.free-online-games-directory. ... ion/13/51/ (warning, addictive!)
If it needs persistence, than of course, a server-side language would have to be involved. I was speaking more about interface implementation
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 3:26 pm
by Eran
By the way, I was wondering - what is the advantage of AMF as opposed to the standard model of GET/POST request/response? seems the difference is semantic only
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 3:42 pm
by josh
Most games need persistence, most use at least a high score card or ability to save game status. You're right though we can't know for sure because the OP didnt give a lot of background info. Honestly I haven't tried out amf, flash has built in XML parsing and so did PHP ( simplexml ) so I just used that
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 5:36 pm
by VirtuosiMedia
pytrin wrote:Flash would definitely be a much more capable platform for game development than PHP / JS. If you're feeling frisky, I'd also give the canvas element a shot, it can do very nice things (though it won't be very portable).
Canvas can be portable if you include
excanvas. If you go that route, you might also be interested in
processing.js.
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 6:14 pm
by Eran
I meant portable to other platforms (desktop/mobile)
Re: PHP Gaming basics
Posted: Mon Dec 08, 2008 7:47 pm
by Christopher
I did not see it mentioned in the discussion, but the bottom line is that you need to store the shared game data somewhere -- and something needs to poll that shared game data to know when a change has occurred. I would design the system to abstract the shared data and the polling. You could start with the shared data in a database. And start with a Javascript timer making an Ajax call to poll.