Gamestudio Links
Zorro Links
Newest Posts
Blobsculptor tools and objects download here
by NeoDumont. 03/28/24 03:01
Issue with Multi-Core WFO Training
by aliswee. 03/24/24 20:20
Why Zorro supports up to 72 cores?
by Edgar_Herrera. 03/23/24 21:41
Zorro Trader GPT
by TipmyPip. 03/06/24 09:27
VSCode instead of SED
by 3run. 03/01/24 19:06
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
3 registered members (VoroneTZ, monk12, Quad), 829 guests, and 4 spiders.
Key: Admin, Global Mod, Mod
Newest Members
sakolin, rajesh7827, juergen_wue, NITRO_FOREVER, jack0roses
19043 Registered Users
Previous Thread
Next Thread
Print Thread
Rating: 5
Page 2 of 3 1 2 3
Re: Something EVERY MP programmer should read [Re: fastlane69] #53457
11/04/07 21:38
11/04/07 21:38
Joined: Sep 2003
Posts: 9,859
F
FBL Offline
Senior Expert
FBL  Offline
Senior Expert
F

Joined: Sep 2003
Posts: 9,859
http://web.cs.wpi.edu/~claypool/nossdav06/pdf/palant.pdf

Just stumbled upon it - it's about Dead Reckoning.
Still need to work through it completely...

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_ Offline
Expert
Damocles_  Offline
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_] #282913
08/04/09 15:59
08/04/09 15:59
Joined: May 2009
Posts: 445
Peine, Germany
Razoron Offline
Senior Member
Razoron  Offline
Senior Member

Joined: May 2009
Posts: 445
Peine, Germany
most of the links don't work.

Re: Something EVERY MP programmer should read [Re: Razoron] #284063
08/11/09 14:04
08/11/09 14:04
Joined: Feb 2009
Posts: 2,154
Damocles_ Offline
Expert
Damocles_  Offline
Expert

Joined: Feb 2009
Posts: 2,154
all the links still work.
better check your browser settings...

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_ Offline
Expert
Damocles_  Offline
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_.php

This 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: Damocles_] #336797
08/06/10 12:16
08/06/10 12:16
Joined: Nov 2002
Posts: 913
Berlin, Germany
S
SchokoKeks Offline
User
SchokoKeks  Offline
User
S

Joined: Nov 2002
Posts: 913
Berlin, Germany
Great read, I've seen that article before and I've always wanted to implement this to 3DGS. However, you may not use c_move (especially with glide) as it seems to be quite random when obstacles appears from what I've discovered in my multiplayer tests.

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_ Offline
Expert
Damocles_  Offline
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 Offline OP
Senior Expert
fastlane69  Offline 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? grin

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: fastlane69] #337056
08/07/10 22:09
08/07/10 22:09
Joined: Feb 2009
Posts: 2,154
Damocles_ Offline
Expert
Damocles_  Offline
Expert

Joined: Feb 2009
Posts: 2,154
Its less about how clients exchange data.
Such a modes can run peer to peer or server controlled.

Its more about how the game-world is calculated.

In a classic client-server game, the server does all the
logic, calculations and oversees validity.
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.

I know its how Starcraft 1 worked (looking at the networking
commands). So I assume SC2 is very similar to that.

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 Offline OP
Senior Expert
fastlane69  Offline 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.

Page 2 of 3 1 2 3

Moderated by  old_bill 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1