Some key structural changes
After some long thinking and research I decided that the code was far from perfect. Microsoft promotes the use of the component based architecture
it's put in place for XNA (Component Model) so I did some remodelling to the whole project and broke it down in to sub projects.
An XNA game includes a component collection and each key aspect of a game is therefore more than a simple class file, it now becomes a loadable
module that can be picked up and reused throughout the games lifecycle. Such an idea promotes the idea of declaring smaller lightweight
bjects that you simply repeat using.
My current understanding of the XNA framework means I can scale the project much like i do at work with web applications.
I have since broken this project down in to 3 key solutions.
First theres the game itself, this also acts as a networking client for handling things relating to communication to a server like chat and game object positioning.
The second is the server application of course which needn't even be anything to do with XNA for the most part and could potentially run on remoting, sockets or service based calls for communication.
Finally the third solution is the common one that contains all globally required objects, things like a users login details, a map object, economic objects for trading systems, many different things can live in here.
This solution mostly contains lightweight objects that can be passed between the other 2 but can also act as a container for interfaces that define rules for both ends of the communitions.
Each solution will likely be built up of various projects like the current client solution i have contains a single project that merely handles the rendering of the environment so a whole world can simply be ripped out and replaced very easily long term by doing nothing more than replacing a single assembly.
The potential here is that any bugs found need only be a lightweight change to small areas rather than a whole application upgrade.