init and quit are self explanatory.

the main server loop will have three main phases:

* receive messages from the clients
* update the server-side game world
* send all updates out to the clients

As far as possible multithreading goes, each of these main phases can run several operations at once; I need to actually *learn* multithreading, what better excuse?

-------------------------

Messages from the clients refers to anything from player movement to text communications to new player connections. Anything that has changed is marked as such, so that it can be sent out again later.

Updating the game world involes updating players or monsters already in motion, loot drop count downs, entity AI and anything else that needs to happen each frame.

Finally, updating the clients is important: anything that has been marked as "changed" needs to be resent to the players. Any new players that have joined need to receive everything as far as client-side data goes.

If a player is in motion, the server will update their internal position, but this *won't* be marked as changed; only the beginning and end (and changes of direction) of a player's movement will be considered changes. Each client will preform their own updates based on the last known information. The server-side updates are required for new connections.

-------------------------

This outline is only the most basic example of the server's operation possible, but it's a good start. I'll need to consider things such as server-specific map data, scripts and other resources being sent to new connections.

-------------------------

class Client:
	ID --unique, incremental
	socket --connection socket
	[stuff]
	[things]