[Alephmodular-devel] Networking module thoughts (was re: Random musings online and thoughts towards 0.4)

[Br'fin <br...@ma...>]

On Wednesday, January 22, 2003, at 01:28  AM, Woody Zenfell, III wrote:

> On Tuesday, January 21, 2003, at 08:12  PM, Br'fin wrote:
>
>> I'll try and come up with a better document in the coming days. But 
>> something I'm curious about now is whether any of the programmers we 
>> have here have an interest in researching and planning a particular 
>> area of code? There is a reason this project's status on SourceForge 
>> is listed as 'planning' we need to develop/derive our own 
>> architecture for this if we want the modules :)
>
> Yeah shall I take a stab at the networking/input system?  I suspect 
> I'm sort of the resident expert on that area.  Anything special you 
> have in mind for that that could inform the design?  How closely 
> should it accomodate the existing code?  (Depends on how willing I am 
> to rewrite it?  I see.  ;) )
>
> Woody
>
>
At the moment, the things that come to mind are
	
	Modular networking
		So things don't care if they are talking with CNetworkRing or 
CNetworkStar
	Modular layers
		So one object is doing the actual interfacing with the network libs 
and a
		higher level is dealing with the actual data being sent back and 
forth. I should say 		that SDL should be treated like another platform 
even down here. (I'm not so sure I
		have the heart for it down here in networking, but I should ;) )
	Separation of GUI and implementation
		I know, I know, this is an ill defined area. But network setup should 
probably
		be of the form GUI->DoNetworkGatherDialog(..., networkGatherOptions)
		If we can bump off the GUI class for another intermediary class, 
that's even better.
		this->networkConfiguration->GetNetworkGatherOptions(...) Thus letting
		configuration come more transparently from a file or other source as 
well.
	Replays need to be maintained
		Even if the server is driving everything, I guess the local machine 
still needs
		the action flags for its own personal replay recording.

As for how closely you accommodate existing code? What is defined and 
documented now is most likely going to stay as is for a good long 
while. Unless there is a decent way to have networking overall be 
flexible enough to affect the action flags like it does now, and later 
be driving a shallow game core that mostly updates the animation's game 
states, you're probably going to be locked into one or another method 
of networking and driving the game.

-Jeremy Parsons