GNet: Too many TGNetObjects?
BlitzMax Forums/BlitzMax Programming/GNet: Too many TGNetObjects?
| ||
Is there an upkeep overhead associated with many TGNetObjects in a game - even if they aren't being changed? I want to have many level objects in my game have their own TGNetObjects - it greatly simplifies the code. I know this will slow things down network wise when a new client enters the game and leaves the game - but if these objects are in the game but not being updated, do they cause any data transfer? The other, more complicated options that don't involve persistent TGNetObjects, all suck :p So I'd hope I can avoid it. |
| ||
I have looked in GNet source, and it appears that there is no overhead for the number of objects - only when they change states: This is inside TGNetHost.sync() - only TGNetObjects that return a syncing message are broadcast. Local succ:TLink 'sync all objects succ=_objects.FirstLink() While succ Local link:TLink=succ succ=link.NextLink() Local obj:TGNetObject=TGNetObject(link.Value()) Local msg:TGNetMsg=obj.Sync() If msg BroadCast msg,obj._peer If obj._state=GNET_ZOMBIE If Not obj._peer UnmapObject obj link.Remove EndIf Wend And this is TGNetObject.sync() - Only objects which are not currently synced (ie: closed or modified objects) return a message for syncing. Method Sync:TGNetMsg() Select _state Case GNET_SYNCED,GNET_ZOMBIE Return End Select Local msg:TGNetMsg If Not _peer msg:TGNetMsg=New TGNetmsg msg.id=_id msg.state=_state msg.data=PackSlots( _modified ) EndIf _modified=0 Select _state Case GNET_CREATED,GNET_MODIFIED _state=GNET_SYNCED Case GNET_CLOSED _target=Null _state=GNET_ZOMBIE End Select Return msg End Method So it looks like the verdict is that it is safe to have large numbers of GNetObjects - except for the caveat that when people join the game in session it should slow everybody down while all the information is transmitted to them. I'm not sure if this workaround for that will work - but I might run two different TGNetHosts on the machine at once - one will have minimal objects and act as a sort of game-lobby, which will accept connections etc and keep people from slowing down the current game if they join in progress - and the other will contain the TGNetObjects of the actual game - and people will only join this at the start of a round. |
| ||
I have looked in GNet source, and it appears that there is no overhead for the number of objects - only when they change states: This is inside TGNetHost.sync() - only TGNetObjects that return a syncing message are broadcast. Local succ:TLink 'sync all objects succ=_objects.FirstLink() While succ Local link:TLink=succ succ=link.NextLink() Local obj:TGNetObject=TGNetObject(link.Value()) Local msg:TGNetMsg=obj.Sync() If msg BroadCast msg,obj._peer If obj._state=GNET_ZOMBIE If Not obj._peer UnmapObject obj link.Remove EndIf Wend And this is TGNetObject.sync() - Only objects which are not currently synced (ie: closed or modified objects) return a message for syncing. Method Sync:TGNetMsg() Select _state Case GNET_SYNCED,GNET_ZOMBIE Return End Select Local msg:TGNetMsg If Not _peer msg:TGNetMsg=New TGNetmsg msg.id=_id msg.state=_state msg.data=PackSlots( _modified ) EndIf _modified=0 Select _state Case GNET_CREATED,GNET_MODIFIED _state=GNET_SYNCED Case GNET_CLOSED _target=Null _state=GNET_ZOMBIE End Select Return msg End Method So it looks like the verdict is that it is safe to have large numbers of GNetObjects - except for the caveat that when people join the game in session it should slow everybody down while all the information is transmitted to them. I'm not sure if this workaround for that will work - but I might run two different TGNetHosts on the machine at once - one will have minimal objects and act as a sort of game-lobby, which will accept connections etc and keep people from slowing down the current game if they join in progress - and the other will contain the TGNetObjects of the actual game - and people will only join this at the start of a round. |