Typically when approaching a problem like a client/server architect I like to start at the backend to get a basic framework established so that come time to begin to work on the client aspect there’s something to action against.
So after mulling this around in my head I’ve settled on the follow approach for structuring the backend.
To begin with on the server I’ve defined the classes illustrated above. Each of which is responsible for a particular area within the overall application. A quick rundown of the elements is below.
This class represents the main program thread and is responsible for setting up the various components used by the system.
The SocketMgr class handles the UDP socket created to receive client requests. We’re using UDP since it’s a lightweight transport suitable for shifting small packets quickly. Since this is a connection-less transport the SocketMgr passes the requests it receives to the ClientMgr which maintains client state.
The ClientMgr class handles the allocation of data to the currently connected clients, each of which state is held in a collection of Client objects stored by the class.
This class identifies a unique remote device ‘connected’ to the server, they will also contain a reference to World Entity instance which represents the user in game.
This the model space for the game storing at items within it, including the player avatars. These are represented by Entity class instances.
At it’s most basic this represents any actionable item within the game.
The plan here is to keep these nicely decoupled such that for example on the client the World class can be easily included to maintain a local client copy of the current server world state (or thereabouts).
I’m a lazy programmer, so reuse reuse reuse.