Re: Shared game-data

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Mon, 01 May 2006 12:37:41 GMT
Message-ID: <pin5g.20314$vy1.4584_at_news-server.bigpond.net.au>


Alvin Ryder wrote:

> 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.
> 
> I suspect they use distributed servers and it all probably works
> similar to how domain name servers (DNS) work on the Internet but as
> I've said before, this is a sub-speciality I've never worked with so I
> just can't say for sure.

DNS is prolly not a good model given its baseline data is expected to be relatively slow moving (thinks Galapagos turtle). If someone ever found a way to reset the TTL for every DNS entry to 60 secs the net would melt down in no time flat (unless no DNS requests were being made). Its viral nature which makes it viable now would be its own undoing.

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

> 
> To achieve decent frame rates you only get milliseconds to compute
> everything so optimizations are mandatory. As for smarts, often things
> that appear almost magical turn out to be simple.

Simplicity is very RM (with the exception of nulls and a few other bits). Claims to the contrary suggest a limitation in the beholder moreso than the beheld. That said as I pointed out before the mainstream attempts to implement the RM are basically passive/reactive unlike what the game requirement to be very active. It should be doable though but I think the net will have to get supercharged first.

Cheers, Frank. Received on Mon May 01 2006 - 14:37:41 CEST

Original text of this message