Re: Shared game-data

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Sun, 30 Apr 2006 22:42:05 GMT
Message-ID: <13b5g.19825$vy1.5284_at_news-server.bigpond.net.au>

Dmitry A. Kazakov wrote:
> On Sun, 30 Apr 2006 07:09:57 GMT, Frank Hamersley wrote:

[Quoted] >> 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.
>> [..]
>>
[Quoted] >> 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.

[Quoted] >> 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.

The mainstream SQL DBMS packages are much more passive than this and don't have basic integrated temporal support let alone something this dynamic. Are there any specialised engines around or are game developers building their own infrastructure each time?

As Bob said though it would be an interesting line of development for general purpose databases to move towards this space.

Cheers, Frank. Received on Mon May 01 2006 - 00:42:05 CEST