We're testing a simple Pong game to see how well we can use SFS for real-time games. The client updates the ball and receives infrequent messages from the server which are used to synchronise the client and server data.
We're seeing some jumps in ball position when getting server updates and my first thought was it was simply due to the lag involved. However we determined that even on a PC with a ping of 30ms to our server the same thing happens. That seems too low to cause what we see.. it means a server packet should take only about 0.01s to reach the client.
One obvious thing is that our server and client aren't running equivalent simulations, of course.
But I also wanted to ask if SFS adds any overhead, if its message handling/sending is slow at all?
Client/Server synchronisation - does SFS add extra lag?
Pong isn't a simple accomplishment, but it's an interesting study.
SFS can receive and broadcast thousands of request per second and the added lag is negligible.
The problem with a real time game is that you need to make it playable for users whose ping time will vary from 50ms (lucky) to 200ms (not so lucky) or worse.
This means that you can send an average 10-20 updates per second and use client-side prediction techniques for making the ball movement as smooth as possible.
As I already mentioned a "brute force" approach where you try to send as many updates as possible won't work without the support of good compensation techniques.
Try googling for "client prediction techniques" and similar and you'll find a lot of resources.
I've found a couple which look interesting:
http://www.valve-erc.com/srcsdk/general ... rking.html
http://www.gamedev.net/reference/list.asp?categoryid=30
SFS can receive and broadcast thousands of request per second and the added lag is negligible.
The problem with a real time game is that you need to make it playable for users whose ping time will vary from 50ms (lucky) to 200ms (not so lucky) or worse.
This means that you can send an average 10-20 updates per second and use client-side prediction techniques for making the ball movement as smooth as possible.
We're seeing some jumps in ball position when getting server updates and my first thought was it was simply due to the lag involved.
As I already mentioned a "brute force" approach where you try to send as many updates as possible won't work without the support of good compensation techniques.
Try googling for "client prediction techniques" and similar and you'll find a lot of resources.
I've found a couple which look interesting:
http://www.valve-erc.com/srcsdk/general ... rking.html
http://www.gamedev.net/reference/list.asp?categoryid=30
We still see substantial jumpiness with a ping of ~30ms which to me is odd... and makes me think the problem might be our code after all. We are using prediction techniques but when the server sends an update, we still get jumps. I'm aware of more elaborate measures but don't really want to use them
I thought an easy thing might be to estimate the lag, and when I get a server update immediately apply a prediction step of lag/2.
I thought an easy thing might be to estimate the lag, and when I get a server update immediately apply a prediction step of lag/2.
We still see substantial jumpiness with a ping of ~30ms which to me is odd
What do you mean by "jumpiness"? Can you expand on this
could you explain more about what kind of messages are you sending?
Are you using the raw format? (off-loads the client from parsing)
Did you check if the problem is on the client side? (too much data in too little time...)
Are you using AS2 or AS3 on the client side?
- mistermind
- Posts: 131
- Joined: 15 Sep 2007, 01:33
- Contact:
A good method of prediction used in most of the MMOs nowadays is only sending the initial value of the client input. An example:
Instead of sending the ball position in real-time, send only the direction and speed where its heading, and let the other client handle the rest.
On a platform game for example: Instead of sending real time information of "this player is going left", send only the moment he pressed left, then the moment he released left. I don't know if that will help at all, but it seems these tricks can help you out if you're problem is handling too many packages.
Instead of sending the ball position in real-time, send only the direction and speed where its heading, and let the other client handle the rest.
On a platform game for example: Instead of sending real time information of "this player is going left", send only the moment he pressed left, then the moment he released left. I don't know if that will help at all, but it seems these tricks can help you out if you're problem is handling too many packages.
Return to “SmartFoxServer 1.x Discussions and Help”
Who is online
Users browsing this forum: No registered users and 89 guests