Ajax Is Not Fast Enough

[mobone]

I'm making a game, and using setTimeout for the attack speeds. But sometimes the attack speeds are too fast for ajax, and the battle misses a beat. I would rather have a php running the battle in the background using session variables, and use sleep to slow it down a little. Then have another page for ajax to connect to and send the session data.Basically I want ajax to call the battle page, to start the script, but not wait for it to finish.Is this possible?

[Ingolme]

If this is supposed to be a multiplayer online real-time game, Javascript and PHP are not the technologies you're going to want to use.You can use Flash or Java or program something in C++ that connects to a server with sockets (and dedicated servers for that kind of technology are not cheap)AJAX uses HTTP requests: It send a request to the server and has to wait for the server to respond before continuing. The speed depends on the location of the server, and your own home internet speed. An "almost-real-time" game done with AJAX could drain your monthly bandwidth (and CPU usage with PHP) very quickly if you're hosting it on a normal web hosting server.

[mobone]

If this is supposed to be a multiplayer online real-time game, Javascript and PHP are not the technologies you're going to want to use.You can use Flash or Java or program something in C++ that connects to a server with sockets (and dedicated servers for that kind of technology are not cheap)AJAX uses HTTP requests: It send a request to the server and has to wait for the server to respond before continuing. The speed depends on the location of the server, and your own home internet speed. An "almost-real-time" game done with AJAX could drain your monthly bandwidth (and CPU usage with PHP) very quickly if you're hosting it on a normal web hosting server.

I was just trying to use setTimeouts to set how fast the players hit each other, since php doesn't have anything time based like that. I could just take the speed part out and just run the whole battle once and then output the results, unless you can think of a way to implement different speeds of attack with php.

[Ingolme]

PHP runs on the server before a page loads. Once the page has loaded, the PHP won't run anymore.You can't use PHP to make real-time applications. If you completely omit PHP you can make Javascript do all the work without having to perform AJAX requests. The only problem being that the game could not be an online multiplayer game and could only be single-player.

[mobone]

PHP runs on the server before a page loads. Once the page has loaded, the PHP won't run anymore.You can't use PHP to make real-time applications. If you completely omit PHP you can make Javascript do all the work without having to perform AJAX requests. The only problem being that the game could not be an online multiplayer game and could only be single-player.

Just some guy also saw security flaws in just using javascript. Someone could edit their variables.

[Ingolme]

There aren't any "security flaws" if the Javascript isn't in communication with PHP, however people would be able to cheat by studying the source code of the game. But there would hardly be a point in cheating since the game wouldn't be "online."If you want to make online multiplayer games you are most likely better off learning something like Flash, or a language like Java or C++, and then learn about socket connections.HTTP is a request kind of connection: A client makes a request to a server, the server sends data to the client and then closes the connection.Socket connections are ones where the server pushes data to the client and both the server and client are listening for incoming data.

[justsomeguy]

The main thing you need to realize with ajax requests is the time required for the response to come back. Most browsers have a limit on how many connections they can have open with a single server at the same time. I'm pretty sure for IE that limit is two. If you're sending requests at a higher rate than they are able to finish, eventually you're going to fill up the request stream and the browser isn't going to respond to anything on that server, the only thing it's going to be doing is waiting for a ton of queued requests to come back.Sending one request every 2 seconds is about the lowest I would want to go, 5 seconds or so would be a lot better. So you need to set your game up so that you're sending one request every few seconds, and just build your game around that. You could also make it turn-based, so that someone fills out everything they want to do on their turn, then they hit a button to send the entire thing to the server and it runs the turn and shows the response, then the next guy goes (see Fallout and Fallout 2 for good examples of turn-based combat). The game design is up to you, just build it around the idea that you're not going to be able to send more than one request every few seconds. If you want requests to take less time, you should look into getting a dedicated server on a fast network, that will at least reduce the server overhead. Especially if each request results in database work being performed, and as you get a lot of data in the database, each request is just going to take some time. Just be conscious of that and don't overwhelm the browser's request stream.The other thing you can do is make sure you're sending and receiving as little data as necessary. XML has more overhead than JSON, for example, and there's generally no reason to send whitespace except in text strings. If requests send the same HTML back with different content, just put the HTML on the HTML page and only send the content to fill in the different parts.It's fine if you need to send 4 or 5 requests all at once, I've got an application where clicking some buttons might send out 5 requests or so. But it's not sending them in a loop, so eventually they all finish. When you're sending requests in a loop or in sequence you just need to realize the limits involved.