Re: Shared game-data

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Mon, 1 May 2006 12:16:00 +0200
Message-ID: <1u4mimaicw3wo.zlg7zxcd5mwz$.dlg_at_40tude.net>

On Sun, 30 Apr 2006 22:42:05 GMT, Frank Hamersley wrote:

> Dmitry A. Kazakov wrote:

>> On Sun, 30 Apr 2006 07:09:57 GMT, Frank Hamersley wrote:

>>> Alvin Ryder 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.

> 
> I guess with N players emitting state info you have order N packets 
> floating around and having to be processed by each host so scaling would 
> be linear.

Each host has one connection for outgoing packets and n-1 connections for incoming packets. I.e. it is n x n connections. For unicast it is n-1 outgoing and n-1 incoming connections, i.e. n x 2(n-1). When n->oo, it is 1:2.

>>> 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.

> 
> Now some CDT flavour.  I am speculating that what gamer builders need is 
> a massively distributed database capable of synchonising in advance of 
> "game time" so it can then generate events to the local gamers instance 
> as they become apparent.  Of course it would have to be damn quick at 
> all this to make the first person action game viable.

In the opposite camp it is called "middleware", "software bus" etc. They and distributed DBs will definitely meet some day.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Received on Mon May 01 2006 - 12:16:00 CEST