glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[glob2-devel] New Net Engine, New Map Headers, ready to merge


From: Bradley Arsenault
Subject: [glob2-devel] New Net Engine, New Map Headers, ready to merge
Date: Tue, 3 Jul 2007 22:55:49 -0400

Me & Kieran are doing some last testing but, as far as I can tell, the whole rewrite is ready to merge. He is a broad summarry if almost all the changes:

LAN and YOG:
I've implemented LAN, which was the last unimplemented feature, and it seems to work great. The LAN broadcasting works fine. It simply sends a packet to the subnet ( 255.255.255.255) twice a second. On the recieving end, the list keeps track of incoming packets and forms a list of games. It times out games that grow old fairly quickly and intelligently ( 1.5 seconds), so no need to manually refresh the list of games. My testing indicated that it worked, and I was able to play a game with myself using the LAN system.

Of coarse i've done a whole new YOG. It feels stable, the code is very well organized: data is seperate from code, for example. There are scripts that take the tedious work out of creating new sub-classes of the NetMessage and all of the event classes (from YOG events to multiplayer game events). Mostly every function is documented and the majority of member variables are documented. Thinking through the communication state-machine can be a bit tough but thats life. I've tried to model the system in an event-based fashion, both in YOG<>client communication and client<>gui communication, so to minimize the number of confusing state machines. Theres also some basic unit tests for net communication in the event that more bugs surface, atleast one layer can be garunteed functional.

New Map Header Format:
The new map headers have also been completed, and the ramifications throughout the code have been cleaned up. These map/game headers have better defined semantics so they will be easier to change in the future.

A Change In Translations:
Also, I've organized the translations in the translation files alphabetically. Don't hate me, there plenty of good reasons. I was able to discover, for example, duplicate entries of [workers]. It makes searching for a translation less of a chore. The original grouping within the file wasn't consistant ([wheat] and [Wheat] where seperated signifigantly), and most "groups" of similar translations start with the same text anyhow so even alphebetically they are still grouped. I solved the issues with alphebeticall codewise also, due to the fact that certain translations (AI names, building names, unit names, ressource names) where meant to be in a particular order for the code, so these where all solved (however, some keys where renamed in the process). The check_translations.py script will automatically organize the keys alphebetically in case new keys are added out of order.

Other Stuff:
Of my other changes there has been lots of general cleanup, (for example all Order's use smart-pointers now), I also happenned to find a bug that caused any Echo AI to crash when loading a saved game occassionally (it was due to incorrectly serializing Order). Since the format was broken anyway I removed the old Nicowar code entirely.

I decided not to do zipped maps just yet, as they aren't really needed now. I came to the realization that a gz file doesn't hold multiple files, its just a compression of one. I would have  to add another layer ontop of the gzip code we already use, (like libtar, for example) thats another dependancy, a whole new part of the system ....... more work than its worth right now.

A another break in the format won't be as signifigant, codewise, since the format is the same, its just now in a gz file. We could even do a sort of auto-detection, if opening it as zip fails try the old way (chances are 99.99% that the signature checks will fail if the zip code itself doesn't report error), so players don't even notice for there own maps.

Data wise we need to do a new directory for maps on the syncmaps script, inform the wiki that the format has changed, and we need to get a new YOG server running parrallell to the existing one. Everything now revolves arround port 7486, both the UDP LAN broadcasts and the YOG server are the same port.

Other than that, I'm glad the system is finally done, several months later.
--
Really. I'm not lieing. Bradley Arsenault.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]