The network
The network works in this way: the server network object contains a list of sockets, each socket representing one unique client and a global send variable. Each socket also has a local “must send” variable representing all data that MUST be sent. The global send variable is used to update game state messages that do not contain vital one-time only information. Each cycle, the server scans for new incoming connections and creates a new socket if such a connection is found. Then it scans for any new data from each of the sockets and puts that data into a received variable that must be manually cleaned up (to indicate that the message is read) by something else. When new data is received from a client, the server sends out all available data from the global send variable and the client-specific send variable to the client. It is presumed no messages are missed by the client. The client specific send variable is cleaned out after it is sent. All such data variables come with their appropriate lock variables.
The client network does not run in its own thread. Each cycle, the client network will attempt to connect to a network, and if connected will attempt to read once and send once from the network. If data is available to be sent at the beginning of the cycle, it will be sent. If not, then a filler message is sent as a request for new data from the server.
The main loop
This part of the program is done rather stupidly and can/should be changed. It is done the way it is as the engine was scrapped from an older game where such a design made more sense.
The mainloop gets instantiated at the entry point of the program and the loop function gets called once every cycle. The frequency of these calls is at the discrepancy of the entry point. As far as the mainloop is concerned, one loop call represents one unit of time. Of course, any game object created by the mainloop may call system time functions at their own discrepancy.
When instantiating, the mainloop looks for the level.xml file and instantiates objects based on parameters in the xml file. For example, the network entity is listed as an entity in the xml file and is specified whether the network should act as a client or a server. In addition, special classes are stored in the enDict variable which is a globally accessible dictionary to specific objects that deserve special attention. This is an efficient way to generalize special access but it’s also awkward and I see no reason why these classes should not be instantiated through a less convoluted system asides from the fact they are already implemented in this way.
The mainloop then calls the draw and update functions for all the objects in its endict (which include all objects instantiated through the xml file and possibly more).