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.