multiplayer game how to

mikawhat

I have developed a quiz game, based on AJAX, which is running fine for a single player. Now, i need to make the same game to support multiple users in one game. E.g., someone creates a game, other people join it (max 4) and they all start playing together....

I have no idea how to create it, not even if this is possible with php. If anybody could advice it would be really helpful! Thanks.

etully

The poor man's way to do this is to make a table in MySQL called "games" that has a game ID and a user ID. When a user creates a game, you find a game ID that doesn't exist in the table yet and insert that new number along with their user id. When someone joins that game, you add another record to the table with the same game ID and the new user's id. (So the games table would look like this:

game_ID user_ID

1 75
1 246

This tells you that there are two people in game #1 and their userid's are 75 and 246.

Then in your Ajax code, you send messages up asking for updates to game #1. All the players in game #1 can see the events that happen in their game.

The problem with this solution is that the server is taking a lot of HTTP requests from Ajax. This is fine if you only have a few hundred users but the server will run out of available connections.

A larger solution involves a multiplayer server like Electroserver or Smartfox. These integrate well with Flash applications but not so well with Ajax. It can be done with Ajax but it's a little more tricky. These multiplayer servers fix the connection problem but they get pretty expensive and require knowledge of Java programming.

Do it with Ajax and MySQL to build your prototype and get some investors and then use the investor's money to get Electroserver and build the game in Flash.

mikawhat

Thank you for your post. For now, as you said, the php-mysql solution is the one to stick with.

So there are no other functions (in the many php functions i'm not aware of) to use for developing this kind of projects?

The solution is to just send a request every second and get a reply if a user has answered etc?

etully

Right. Program it so that you hear "000" or "false" if the other user hasn't made a move yet.

Querying once a second is fine for chess or checkers but sometimes you need faster responses. There is another way to program this but it essentially keeps HTTP connections open constantly. So you can really only do this for yourself and a few friends. If you release your web game to 50-100 people, you will render your web server useless.

Make a call to your script which does this:

check current time
loop until time > current time + 30 seconds
check database for update from other user
if yes, print details, exit script
end loop
exit script

So as you can see, Ajax would hit this script and the connection would stay open for 30 seconds or until the other user took some action, whichever comes first. Then, as soon as the 30 seconds ends and Ajax's connection to the server is closed, you open a new connection to the server and listen for another 30 seconds.

This technique will kill a web server but you can get away with it if only you use a password or something to limit this to no more than 10 people or so. (You can opt to increase the number of simultaneous connections that Apache is allowed to take on but that will demand more RAM in your machine.)

mikawhat

I see! for now it will be fine if using this method. But in the future? There's nothing to improve on it right? as you said it should be built in flash...

etully

Flash would be my choice for a good list of reasons. (Not the least of which is that I work for a video game company who makes Flash games).

The number of available connections to the server is a limit. Apache wasn't designed to be a game tool. It was designed to serve up web pages. Sure, it can work for what you need but the authors built the tool to handle a different sort of visitor and the max_connections is going to tap out for you too fast.

Multiplayer engines were designed for exactly your needs. Unfortunately, they are designed to interact with client side Java (not Javascript) and Flash. I like Flash.

Of course, you could place a very small, 0 pixel Flash movie on your page. Then you can continue to write your app in DHTML / Javascript. When you need to interact with the server, you interact with the Flash movie on the page and it interacts with your remote multiuser server. This would work just fine except that tools like Greasemonkey (and I think Jetpack) allow the user to manipulate Javscript on the page and they could use that to give themselves an advantage in your game. Since Flash and Java are compiled binaries, they are more difficult to manipulate so there is some layer of protection for you.

If your game was something like chess or checkers, then there is no advantage that can be gained by hacking the Javascript on the page (your move is your move) so that would be 100% secure. But if your game was a sort of shoot-em-up, and you did it in Javascript instead of Flash, then someone could manipulate the JS to give themselves better aim or something.

Start simple. There's really a lot to learn.