[glob2-devel] New Net Code Is Priority

[Bradley Arsenault]

Well I havent had the chance to commit the code for Campaigns (which
is pretty much complete, has the basic required feature set), I have
full intentions to commit it eventually.

Since I there hasn't been much responce about how to go about making
the new YOG and netplay code, I've decided to erase it all! The
starting point for a new YOG is to get rid of the old one. So, Thats
what I'm going to do. I hope I have the chance to commit the campaign
code before then but the chances are slim. I'll try to not commit
broken code, but If I get windows cvs working like I hope to, theres
going to be a series of commits where the net code is shaky and most
of it won't be there.

Heres a quick outline of the new system. Its kind of confusing right
now, I'll make a simpler wiki document soon:

There will be a TextProtocol class which is bassically the interaction
between the system and the sockets for text based protocols (which is
YOG, not in-game stuff). Bassically, this class takes an existing,
open TCP socket, and begins to manage it in a seperate thread.
Everytime it recieves a message, it parses it into a simple name-value
archive (much like the Settings code), and puts it into a queue. The
gui calls a tick function, which bassically calls a callback function
that the gui provided (using boost::function) to handle the messages
in the queue. Sending messages work the same way, they are queued, and
the other thread picks them up in all due time.

The multithreaded design is entirely an internal thing, the interface
will present nothing that seems multithreaded. I chose to do this as
more of a learning process than anything, although having a seperate
IO thread is somewhat usefull for TCP.

The server will use this class, and the callback function in the
servers will be a Connectee class that implements operator()
(boost::bind offers a friendly alternative instead of operator() if
need be). This object oriented design is nice and high level in my
opponion, and will work well.

This Connectee class communicates with the client, bassically
performing basic interaction like login and send/recieve message, new
game. The server class will act as an event pump, for example, if one
person sends a public text message, the server will pump it out to all
of the people. Its trivial to implement.

Most of the existing menus will remain the same, its these internals
that will be changed. All of the existing features will remain there,
but this new TCP and text based YOG will be easier to debug and
maintain for programmers, and will be more reliable (because of TCP
and multithreading) for end users.

I don't have a new system for in-game net play designed yet, but its
going to be a complete overhaul much like the YOG system.

Criticisms are welcome. I won't flame if you guys complain that I plan
to use boost::function, boost::threads, and maybe boost::sockets as
well. I just think they are usefull and fit my goal very well.


--
Whats long and hard and filled with seamen? My submarine!  - Bradley Arsenault