Sign in to follow this  

Implementing a predictive algorithm to calculate current game state

This topic is 2842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

After more or less finishing my browser-based javascript/PHP RTS game, and doing some tests on the server load, I realized that a single server would only ever be able to host one, maybe two games at a time. Obviously, this is not acceptable, so I decided to switch from AJAX to websockets (which are native in google chrome and other webkit browsers, but can be used in other browsers via a flash bridge). Obviously this is something I should have done to begin with, but I mostly just wanted to do it in AJAX to see if it would actually work. The goal of the new system will be to calculate the game state on each client at the same time, rather than once on the server, and sending each game state to all the clients. This works, but it's really resource intensive. By calculating the gamestate separately on each client, the server basically only has to act as a data channel to compensate for the fact that websockets don't work peer2peer. This is really great, but it also introduces some complications. The main complication I'm having right now is how to simultaneously ensure that "sync errors" don't occur, and that the game isn't needlessly laggy. The biggest problem is how to determine when a particular order by one of the players should come into effect. I decided that it would be possible for the server to assign a time to each order that designates when it should come into effect. However, that introduces the problem that the order might not arrive until after it is scheduled to come into effect. This would mean having to recalculate everything that happened from the point the order was supposed to occur, until the present time. This could be mitigated to some degree by having the server designate some arbitrary time t that it adds to the time it receives the order from the client, before it actually takes effect. However, no matter what t you pick, there is always a chance it won't get there until after it is needed. SO, this leads us to the TL;DR section: Should I make an effort to make some sort of compensation code to re-do everything if an order arrives before it is needed? Or should I just have a sync error happen if it arrives after it is needed? What t should I use? Thanks in advance.

Share this post


Link to post
Share on other sites
The brief answer is: Don't start operations for a step/tick, until all commands have arrived for that step/tick. If someone is late, stall the game. If someone is late a lot (or a lot late), kick them, or increase amount of latency compensation (number of steps in advance that commands are sent).

Share this post


Link to post
Share on other sites

This topic is 2842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this