next »

[mrsdf]

I'm looking into developing a multiplayer card game website (don't know yet.. poker, blackjack, probably all of them if it works out). The server part will be mostly php/sql, but I can't really decide on the client side. I've seen various java clients on other websites of the same nature out there, but I'm thinking of using xmlhttprequest/script tag for client-server communication.

Due to the nature of the website, most processing will be done server-side for security reasons, and the client will be just a pretty interface with some numbers and buttons changing, nothing that js can't handle i think.

I got a few things figured out by now.. I need a chatroom, game rooms, pretty bitmaps of people sitting around a table, dynamic graphics loading, a way to check for player latency, constant client-server data exchange.

So far, I can't think of anything that JS can't do for the client side, but I also know it can be done, and it has been done in the past using Java or Flash. I personally hate flash, and have .. noob to medium Java skills , but I could fix that. I also know that the big websites probably had a very good reason for coding stuff in java for the client side.

Would you code this thing using Ajax?

The only downsides I can see right now are that the source is plaintext and that the client must request data all the time... eg: 10 players/game table * 3 requests/second for each player * 10 tables = 300 http requests/second. I might be happier with the server pushing the data to the client whenever it is needed.

Any thoughts ?

[arms]

if i was going to do it i would probably choose flash.
actionscript is basically javascript and flash will make the animations easier.
so to me, flash = less work.

[perkiset]

I don't know that I see it as an either/or.

JS will make it run on anything, even an iPhone, so that would be my choice. So how do you keep comms up? Perhaps a Java app that is persistently connected and dropping cookies/semaphores/data/whatever such that your JS can pick it up when it needs to... or you could use flash for the same, but particularly today the iPhone can't do flash, if this is one of your targets. Rumors are that flash will be out in the next couple months, and if that's the case, other phones and ultra portables will follow suite.

I think it would be a mistake to imagine that you must code ALL of it using one tool when all of what you described are (for the most part) available to any browser - choose the right tool for each component. Given what you've talked about in terms of traffic, whether it's Java, Flash or JS, packets will be flying - it just depends on the overhead of the protocol. If you go Java you can take Apache out of it and create a dedi-connection... but Apache on the right box would do just fine IMO and you could still use PHP and such for backend processing, which will certainly simplfy backend construction.

Although I have not put lots of users on lots of ajax connections at once, I do have one app where a status bar moves based on a job - so it's coming back up at me about everh 1/10th of a second until the job is done and I get zero troubles. I think the notion of more packets faster is a humnan brain imagination limitation rather than a for-reals 'puter issue. I think that they do it just fine...

[DangerMouse]

Prehaps check out COMET, a reversal of the AJAX principle, that may reduce the number of requests that are required if you went the javascript route. I guess you could argue that you open yourself up to more vulnerabilities using javascript - people are more likely to poke around trying to break code they can read.

DM