2

I made a game in node.js and uploaded it.. it should be 30 - 60 frames per second..
Now I testing it and it runs slow.. I mean in local network it runs a lot smoother

The server isn't that far away.. So any tips how to make the fps better?

What is better xhr-pooling or websockets, what is faster?
The game is set with xhr-pooling like this - 

io.set('transports', ['xhr-polling']);

the game is hosted in appfog

If needed I can post the game link!

julian
  • 4,634
  • 10
  • 42
  • 59

1 Answers1

4

The question here is what are you trying to do? If the server is sending a message to the client for every frame, what you are talking about it basically impossible -- network latencies below 16 ms (60 fps) or 33 ms (30 fps) over the internet are impossible to reliably guarantee. It might work over a local network, and almost certainly can work on a local machine, but not over the internet. If you need to get information from the client to the server and back in the next frame, your round-trip latency needs to be that low, including the processing on both sides. Since both xhr-polling and websockets use TCP, it gets worse because one slow/lost packet will pause everything after it until it finally shows up.

You really need to decouple the rendering from the server as much as possible to make a viable game in a browser. The network just isn't fast enough.

korvus
  • 395
  • 1
  • 5
  • so what i should do? the game loop should be in the client instead in the server? but then people can make hacks easily.. – julian Jul 29 '13 at 19:43
  • The key is to have the server maintain the "official state". For example, I helped work on bazookaguys.com (it was just thrown together, but will suffice). If someone hits the right arrow, the client will tell the server they are moving, and the client will start animating it. If the server later tells the client that the user should be somewhere else, they'll jump to that position. The client acts as if it is authoritative, but can be corrected by the server if it is wrong. We weren't worried about cheating so we did hit detection in the client, and that was full of bugs... – korvus Aug 03 '13 at 05:50
  • A good example would be to look at how the [meteor framework](http://www.meteor.com) does latency compensation. If you change server-side data in the client, the client acts like the data has changed until the server confirms or denies it. That makes it feel fast to the user, while still making the server the authority. – korvus Aug 03 '13 at 05:54