Sign in to follow this  
DvDmanDT

Best approach to a 100% synchronized action game?

Recommended Posts

I'm writing an action game, which'll contain tons of moving and bouncing objects.. The game will run at say 100 fps internally.. Let's say I have 5000 objects.. It's impossible to synchronize 'em all, so I figured I'll go for a synchronized simulation (you know, when all clients do exactly the same thing all the time, like many rts games do).. The player can move left/right, he can jump, he can aim up/down, change weapon, and fire.. One way here would be to more or less send keypresses, and put 1-5 frames delay on them (depending on ping times).. But that might on the other hand make the game feel unresponsive or choppy/laggy.. Then I figured I can send actions/events, and store them, and also store the entire gamestate every x frame.. If I saved every 10th frame, and saved 4 of those copies, I could go back up to 400ms, and modify reality (sortof).. This way, when I fire my gun, I might see it first some ms later, but the bullet would go off at that time anyway.. My question is, do you think this is a good way to go? Do you think it would require too much cpu/ram? Let's say I have a gamestate of 64mb, copying that 10times every second could put pretty heavy load on the ram? Any suggestions and/or better ways of doing this?

Share this post


Link to post
Share on other sites
I believe a synchronized simulation works like this:


while (1)
{
Get user input
Send local input packets
Wait for opponent input packets
Process all local and remote inputs
udate logic
render
}


you need fast network code.

-me

Share this post


Link to post
Share on other sites
Change your design.

Lockstep multiplayer using synchronized seeds with a desire for rapid response to player commands is extremely difficult, and depending on how many players and what level of interaction is required, may be effectively impossible.

Also, why are you trying to run the core at 10ms simulation frames? The usual model is to have the simulation running more slowly than the video update.

--Dave

Share this post


Link to post
Share on other sites
Quote:
Lockstep multiplayer using synchronized seeds with a desire for rapid response to player commands is extremely difficult, and depending on how many players and what level of interaction is required, may be effectively impossible.


I agree! However, we actually do that, with up to several thousand simultaneous players online. It took a while to get right, though.

Quote:
Also, why are you trying to run the core at 10ms simulation frames? The usual model is to have the simulation running more slowly than the video update.


That depends on your simulation. If you're doing forward Euler simulation, you typically want a high physics rate to reduce errors. If you're doing penetration-based constraints, then you want a high collision rate to avoid tunneling. (Yes, there are other ways to avoid tunneling, too)

There are lots of viable game approaches with 100 fps physics rates.

Share this post


Link to post
Share on other sites
To make objects move smoother among other things.. That way they are less likely to miss eachother in air and things like that.. I should add that it's a 2d game.. Using 50 fps for the logic, I figured a oneframe delay would be 20ms.. If I used 100 logic fps, I could use 10ms in lowping scenarios, and I can use 30 or 50 instead of 40 or 60..

I can't change the game design.. This game can be considered an unofficial sequel you see.. The original didn't have network (Liero is the name of the original game)..

As you can see, it's a very difficult task.. My plan is to send all actions to a server, which then sends it out to everyone (including the one who send it).. They then put it in their eventstack.. This way, everyone gets the same messages in the same order.. Then the server says 'this event happends at currentframe+3' for example (there's a framecounter).. This means it could take 30ms or so for a keypress to be happening, which could be a problem.. And that's assuming everyone has 30ms or less in ping to the server, which might not be realistic.. That's when the keeping of the gamestates come in.. I press a key, send a message to the server, and he sends it out to everyone, without adding that 3 to the framecounter.. This means that when the packet arrives, everyone is 3 frames after the keypress.. They then go back to the saved state, add the message, and run the missing frames again until they reach the current time.. Is this possible at all with current systems, or do you have any better ways?

Please ask if you don't understand, and please comment and suggest everything you can think of.. Other than that, thanks for your comments..

Share this post


Link to post
Share on other sites
Quote:

I agree! However, we actually do that, with up to several thousand simultaneous players online. It took a while to get right, though.


You mean the use of a lockstep model for synchronization in There??

Quote:

Lockstep multiplayer using synchronized seeds with a desire for rapid response to player commands is extremely difficult, and depending on how many players and what level of interaction is required, may be effectively impossible.


Yup, traditional ways of hiding latency / minimize bandwidth consumption like extrapolation would out of the picture... Besides that it would be a costy operation to do prediction for thousands of objects you'd get a lot of rollbacks because of the butterfly effect; a small change can make a big difference in such a system.

The only way to keep things perfectly synchronized would be using a lockstep model. But this would make your game not so real-time on a normal internet connection (100-300ms latency). As long as we're stuck with unrealiable, lagged network connections it will alsways be a tradeoff between consistency / real-time interaction.

PS: Is your Liero clone anything like this: http://lieroxtreme.thegaminguniverse.com/about.php
They have network support too, I fail to see how you'd need to synchronize thousands of objects in this type of game :)

Share this post


Link to post
Share on other sites
Because it's 'the right thing to do' in my opinion.. If one object goes wrong, it could create a hole in the map, which another object could then bounce from, and hit a player that shouldn't be hit.. Suddenly, the map is desynced, the health is desynced, and since that player might have died, alot of bullets might get missing for some players.. And since it's very common to get hit several times each frame, you can't really syncronize that either.. Gusanos tries to syncronize the map.. I'm not sure how it's done, but last time I heard anything, it was that it's not realtime, which means one computer can see a hole, and another one a wall at a given frame.. That would also give undesireable effects..

The whole thing is a nightmare.. :p

Share this post


Link to post
Share on other sites
Quote:
Original post by DvDmanDT
Liero

You mean the Liero? Do you have the original source or are you writing a clone from scrath?

If I can do anything for you, I'd love to help.

Share this post


Link to post
Share on other sites
The original source was lost in a harddrive crash.. Another Swede (Gliptic) has reverseengineered the original (with the authors permission) though.. I'm not part of that however, so I'm writing it from scratch..

You can definitly help, I have tons of things to do.. I haven't done very much because of this network problem, but I think I have a pretty good framework.. It renders Ok, though a bit slow.. It'll be based around plugins and mods.. If you think you can help, please contact me over msn (dvdmandt@hotmail.com)..

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
HeHe i was reading the history of Liero, it reads like some myth of lengend! The original source lost! Epic struggle to recreate what was lost! :)

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
Quote:
You mean the use of a lockstep model for synchronization in There??


Well, the avatar starts walking immediately when you press forward, so it's a little more complex than that. We also use UDP, not TCP, so we have to deal with packet loss causing divergence. But, yes, that's the starting point of the architecture.

Share this post


Link to post
Share on other sites
It can't be really lockstep then could it? Or did I mis-interpreted the term lockstep? (With lockstep I assume no states are being updated until everyone has updated the same state for the same timeframe). If you would continue anyways and find out you miss predicted some state at timeframe x, would you roll back or something?

Share this post


Link to post
Share on other sites
Well, our model is something that you can develop if you start out thinking everything is lock-step, but then you want to make sure that the locally controlled client doesn't have to delay for everyone else's input. We have to manage "what" happens "when" on each client (and stay authoritative on the server) -- kind of like running a separate lock-step simulation for each separate object, and then being very careful in the interface between them.

Share this post


Link to post
Share on other sites
Quote:

Well, our model is something that you can develop if you start out thinking everything is lock-step, but then you want to make sure that the locally controlled client doesn't have to delay for everyone else's input. We have to manage "what" happens "when" on each client (and stay authoritative on the server) -- kind of like running a separate lock-step simulation for each separate object, and then being very careful in the interface between them.


Hmmm Im still not sure Im getting this :s

So in the end nobody will wait for each other's input, so predictions must be made? Or aren't there any shared objects between players which they can interact with? Could you please explain the notion of lockstep a bit more as used in that model? It definatly sounds interesting but I can't think of any way of running seperate lockstep simulations and still have an interactive simulation without it being just a traditional deadreckoned simulation...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I think the idea is to bascially break the simulation into smaller units, which though not totally indepenent are discrete enough to be able to be locked step asynchronsouly. For instance if each player was a simple state machine driven by inputs, say up/down/left/right. Those inputs drive the characters movement. For that player a single lock step unit would just be themselves. So all the peers would have a running lock step simulation of each player. The problem arises ofcourse when they interact, becuase the entire system isn't locked step, these interactions will cause unpredicable cascading effects. Also if the one unit becomes desynced only they would freeze up.

Then u have to fall back to periodic state updates to syncrohize the system to an acceptable level of error. Your never going to get 100% sync, but that's not the goal.

I would go with a centeralized client/server, where the server is authoritve for events which can modify the world, like large goauging explosions etc..

Even though your world can have 10000 objects i suspect only 1-5% of them are in view and proably moving/active at once. Using proper scene managment and heavly optimized protocol/update scheme u can get by with such a system.

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
Quote:
So in the end nobody will wait for each other's input, so predictions must be made?


There are cases where you can't lock-step without latency. For example, if there's a gold coin on the ground, and you and I are both close to the gold coin, and try to pick it up, and picking up is an "instant" action (like avatar movement), then both of our clients will predict that we get the coin. The server will break the tie (one of us gets the coin) and ends up sending a correction to the other. The amount of time that you may get corrected for is the same as the round-trip time between you and the server.

Another option to solve the same problem (rather than sending corrections and time travel) is to design latencies into actions. If picking up was an action that took 500 milliseconds, then the server will break the tie before any one of us actually ends up picking up the thing. We've designed our system such that we keep enough state for time travel that both of us could be on separate continents, playing on a server in a third continent, over dial-up modems, and the system will still work. That takes a bit of memory, but our take on that is that memory on the clients is cheaper than bits of bandwidth.

In our model, for each kind of interaction, you can choose points along this spectrum of instantaneous-with-possible-timetravel through latency-and-guarateed-consistent. For things that are unlikely to have contention (avatar movement), clearly choose the instant response. For things that involve many players (applying brakes to a train, or puching the "go" button on an elevator), you sometimes choose to accept some latency, and hide it with feedback animations/sounds.

Share this post


Link to post
Share on other sites
So basically lockstep means "parallel simulation of the game state on all client machines"?

Some time ago, I designed a multiplayer algorithm which worked roughly as follows: each client would have its own "belief state" of the world which it simulates, and the server would have the "real state" of the world, which it then spreads to the clients (not the whole world-state per frame, just a little update), so the clients' belief states are kept at sync. This keeps traffic relatively low and is quite general. Does this algorithm have a name?

-- Mikko

Share this post


Link to post
Share on other sites
Sounds a lot like like "baselining" -- ie, you send user inputs (or deltas) as your typical means of sending updates (I e, "player fired a bullet") but you cycle through all the state and send periodical full state snapshots for objects, so that an object will know that it always receives the sync-ed data every X seconds.

You don't describe how you make sure that quick interactions (jump, shoot, etc) go to the clients quickly, rather than waiting for the potentially long cycle time, though, so it's hard to tell how close it is.

Share this post


Link to post
Share on other sites

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