3 registered members (Ayumi, Akow, AndrewAMD),
1,505
guests, and 9
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Something EVERY MP programmer should read
[Re: FBL]
#274371
06/26/09 16:52
06/26/09 16:52
|
Joined: Feb 2009
Posts: 2,154
Damocles_
Expert
|
Expert
Joined: Feb 2009
Posts: 2,154
|
Some Details about Networking and the Client-Server communication in Unreal. Especially interesting: the Client prediction, wich enables the Client to feel Lag-free in term of immediate inputs such as movement: http://unreal.epicgames.com/Network.htm
|
|
|
Re: Something EVERY MP programmer should read
[Re: Damocles_]
#336788
08/06/10 10:03
08/06/10 10:03
|
Joined: Feb 2009
Posts: 2,154
Damocles_
Expert
|
Expert
Joined: Feb 2009
Posts: 2,154
|
Here an older article about a different Multiplayer concept: Syncronous simulation http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.phpThis is a great choice for games that meet the following criteria: -small amount of command senders / Players, (only have like 2 to 8 players) -large amount of units (RTS as typical example, also other large simulations like in RPG games with many AI Players. -instant reaction not as important (command to action delay) The Syncronous simulation offers the advantage that the network load is tiny, as only commands are send. Each gameclient calculates the full game locally, based on the commands. Starcraft / Starcraft 2 also uses this approach. (In case you wonder why replays cant simply jump forward to any position. It requires to calculate the whole gameflow constantly)
|
|
|
Re: Something EVERY MP programmer should read
[Re: SchokoKeks]
#336800
08/06/10 12:27
08/06/10 12:27
|
Joined: Feb 2009
Posts: 2,154
Damocles_
Expert
|
Expert
Joined: Feb 2009
Posts: 2,154
|
The thing is, that most thing gamestudio users use cant be used.
No c_move, no physics, no events no "wait(1)" in all core functions. Not even the way you use entities normally. (or making shure they always result in exactly exactly the same result)
The core game-play needs to run in a seperate routine with fixed time command cycles. There should be only a single "wait(1)" in the core loop, to avoid any desync. (actually not a wait(1), but a waitfunction that waits for the next command cycle to be processed) Random numbers must be assured to be taken in exact order. using seeding or even a manually controlled random generator.
Other things like the visualization, graphical effect etc can run seperately, as long as they dont affect the core gameplay (only receive data from it)
Anything that runs differently on different machines would result in a desyncronized simulation, and thus make such a system impossible. So framerate dependant calculations should only affect the visualization part.
--
Its also not a typical client-server approach. There is no server wich calculated the gameplay, but its rather just a simple command-packed proxy, to make shure everyone has all info at the correct time.
The full game itself is run on each client seperately.
|
|
|
Re: Something EVERY MP programmer should read
[Re: Damocles_]
#336950
08/07/10 05:13
08/07/10 05:13
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
OP
Senior Expert
|
OP
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
It's a peer-to-peer network model enacted on a C/S platform with the server relegated to the role of an intelligent router and each client becoming an independent peer. Does that about sum it up? BTW, the article is from 2001; how do we know that SC2 uses it? Wouldn't surprise me considering that my description above is "kinda" how battle.net works.
|
|
|
Re: Something EVERY MP programmer should read
[Re: Damocles_]
#337252
08/09/10 19:01
08/09/10 19:01
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
OP
Senior Expert
|
OP
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
"Its less about how clients exchange data. [...] In the "syncronous simulation", each client is calcualting the world logic, only based on usercommands from all clients. The server (such as battle net) would just handle the connections and transfer of the commands. "
That's what I'm saying and I'll show you how:
As you say, P2P is more than just the network; it's also what the apps do with this net traffic.
Consider a 3-tier architecture: presentation, logic, and database. In a C/s environment, the client is solely responsible for presentation, that is presenting the information to the user. The server is solely responsible for the logic and the database, that is a the rules and the charge that dominate the game. In a P2P environment, every peer must have some or all of these components present. Presentation is obvious since every peer is connected to every user, logic is necessary since every peer needs to know how to calculate its own game state and perhaps those of others, and database is important sense each peer it needs to know its own statistics for the world.
So we are both saying the same thing, that even though this is a C/S platform and the packets don't flow like in a P2P, it is in fact being enacted as a P2P architecture in that each client has complete autonomy from the server and the server, as I and you stated, is merely relegated to the role of a fancy router.
As for SC2, I wouldn't assume. I don't know any better but 9 yrs is an eternity in networking. I would imagine Blizzard has been constantly updating their net model in other releases and thus it could bear little similarity to SC. Having said that, if it ain't broke, don't fix it... if it worked in 2001 and works today, then it is truly worthy of attention.
|
|
|
|