Re: Shared game-data
Date: Sun, 30 Apr 2006 12:02:58 +0200
Message-ID: <15bg6cht1jyoo$.7fc1p7jiwbpv.dlg_at_40tude.net>
On Sun, 30 Apr 2006 07:09:57 GMT, Frank Hamersley wrote:
>> mAsterdam wrote: >>> Alvin Ryder wrote: >>>> mAsterdam wrote:
> [..]
>>>>> Could you please tell how good gaming software organizes the >>>>> sharing of data between players? >>>> Multiplayer games are typically implemented using a client/server or >>>> peer to peer architecture. Only a relatively small amount of game state >>>> needs to be broadcast and shared because each player runs their own >>>> instance of the game, all the static game assets are duplicated.
> >>>
>>> Would you agree that this scheme wouldn't work for massively >>> multiplayer games? >> >> Yes, I reckon you're right, that's what I've heard.
>
> [..]
>
> Interesting - I had presumed the bandwidth constraints would put even
> more pressure for each player host to hold as much game as possible and
> apply/generate the state change messages on a minimalist basis. Of
> course this is not "efficient" use of resources but I can't see how you
> would scale up endlessly a centralised server solution.
Yes, but this is not directly bound to uni-/milticast issue. The updates are still better to be distributed using multicast. Though for each to each topology this reduces the total number of connection only by factor of two.
> Of course in a large game terrain not every player needs to be known to
> every other (over the horizon invisibility if you like). However you
> would need some serious smarts to know how far any particular state
> change event must be promulgated if run as a massively distributed
> execution engine.
What puzzles me, if one could invent some mechanism to map the distances on the map to the multicast groups. So that updates would propagate only to the neighbours. Though the main problem with multicast is that parties don't know states of each other. Either one should periodically resent the whole state or an additional unicast channel should be used for "sync" requests.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Sun Apr 30 2006 - 12:02:58 CEST