Can anyone explain how this works exactly? My understanding is that the game will be using this model. If the sync. means that we're all running at the speed of the slowest person, then async would mean we're each running at our own speed, and I guess in this case at the speed of the server? So what happens when people lag? Do they start seeing their units warp around and suddenly blow up? Will I - person who's not lagging - see my lagging opponent lagging?
Not Quite Asynchoronous, more so that the Sim is handled by the Server, and the Clients only receive the data they need and render the graphics. Mike
So this will work much like an FPS does, when someone lags w see him warping around, while he sees his game being extremely unresponsive and warping around. How's the "lag" handled?
The warping in FPS games is the server trying to compensate for where the client thinks it is. To syncronize the local camera with the server camera without any nasty jumping around, the server has some give to it. Something like that shouldn't be necessary in an RTS. If the server is authoritative you should only see warping if you have a bad connection yourself, and others would not see that warping themselves. But it might have delay on commands since you can't execute them locally. It should still be less than in supcom where as knight pointed out, there is 500 ms just to be safe. The delay in a server system should be no more than your ping. And I guess if someone is hosting the game locally they'll have the host advantage. See if 100-200ms advantage matters in an RTS.
How is the processing load shared then? How do other RTS games handle this? Because from we've heard, our CPU power is the limiting factor.
In a similar way to what happens when your CPU is too slow in an FPS; the server carries on, and you process what you can. As long as the server doesn't become bogged-down, it dictates what everyone else does. You try your best to keep up.
In the network model we have if you disconnect for a moment you'll eventually see the game world pause, though you'll still be free to move your camera around. Once you reconnect the game will jump (or we might fast forward) to the current time. If you issued orders just prior to being disconnected they won't be acted upon until your connection returns. Others in the game won't notice anything different at all. Your units will continue to act on their existing orders, including moving to their next location or attacking enemy targets. If you've queued up enough orders prior to being disconnect it's plausible the enemy players won't even be able to tell you've gone offline. There are a number of other posts on these topics, but I'll reiterate here. No load sharing between players; one server does all of the gameplay sim work. Clients take inputs from the player (unit commands, view location(s)) and pass them on to the server and take updates from the server (unit movement, combat, terrain destruction, etc.) and display them graphically. Most other RTS games also don't do any load sharing, every player is doing 100% of the work. They take inputs from the player, tell everyone else what the inputs are and everyone else tells you what inputs they did, then everyone takes one step forward each doing all of the exact same sim work everyone else does once everyone acknowledges they've sent and received everyone's inputs. This is why a single slow PC will bog down everyone. It's also why it's so damn easy to cheat in most RTS games; every client knows everything everyone else is doing by necessity of the system.
Only insofar as the AIs - each player "brought along" 1 computer player, and was responsible for the processing of it (if the player left, that computer left too). An interesting side effect was that each computer player could be using a different underlying AI.
Thanks for the replies , this is starting to sound nicer and nicer. Any one knows of an RTS that currently uses such a model? I'm interested in what people had to complain about
The original TA was similar. I don't know of any traditional RTS that use client server (though I'm sure there are others). However it's almost exactly the model used by games like League of Legends. Pretty much every FPS / MMO game uses similar client / server systems, though they do some level of client side prediction and client authority due to the direct drive player control feeling sluggish and laggy if you have to wait for a server response to move.
LoL, MMORPG and FPS are relatively low client-side processing applications right? Taking SupCom as an example, the current FAF players are mostly using i7 computers, and really only handling processing for our own units right? So in a 2v2 pushing the unit cap, I believe our computers are already slammed, not in data transfer, but in processing power. Will going to 64-bit really help unlock that much more power that 1 computer can now handle the work of 4? And worse yet, how would it handle a 4v4 Setons-sized game? :shock: Raw processing power is the bottle neck right? Not internet connection right? Or am I missing something here?
Nope, they are handling everyone's units at all times. Basically it's just not comparable. 64-bit doesn't do anything other than give us more memory to play with. In a synchronous game raw processing power matters. In PA it only matters for the game itself on the server and for rendering on the client. Basically the clients don't do much other than render. BTW TA was async and did actually distribute the work between machines, even for players. Each player basically simulated their own units (and potentially some AI).
