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 _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
