D3: Basic Architecture Decisions
In order to decide on the basic architecture for DPMud3 (I’ll just call it D3 from here on out), I first needed to build an understanding of the domain, then consider the goals and synthesize a basic approach.
The good news for me is that this is the third major version of this particular application, and in years past I spent way too many hours spending other MUDs and similar games, so I’m pretty well versed in the domain. To give a very quick overview: The key parts are that we model a virtual world in terms of rooms, passages between those rooms, items and actors which can either be players or non-player characters controlled by the game. Interaction happens in real-time via text which means that players express their intentions through simple text commands which must be parsed, and they learn about their environment through textual descriptions of things and events at their locale. The system needs a way to maintain a shared state for all the players, to communicate events as they occur (initiated by players or by other parts of the system such as computer controlled actors) and a framework for creating the AI that brings the non-player actors to life.
The first goal for this exercise is to build a real application not just a collection of samples artificially glued together but at the same time to try out new EF features such as POCO, model-first, mockable-interfaces, the n-tier APIs, T4 for code generation, etc. Another key goal is to use good architectural principles and popular app building patterns which means carefully separating concerns, using Inversion of Control to facilitate mocking and test driven (or at least very carefully tested) development, to create an n-tier architecture with WCF-services and a Silverlight client, and to use a model-view-controller pattern to simplify the creation of multiple views and controllers which share a common model.
The biggest challenge in synthesizing a design out of this domain and these goals is reconciling the multi-player real-time communication aspects with the goal to use and demonstrate EF (and to do so in a way that will be educational to folks building business apps rather than old-style multi-user games). The DPMud solution from the beginning has been to ask that you suspend disbelief about one architectural decision: we are going to use transacted database updates as a real-time communication mechanism. While this is almost certainly not the most efficient, scalable way to implement real-time communication, it does mesh very well with the EF and with the rest of our goals. It also has the potential to be a nice stress-test for the systems involved, and we do have the option to apply more hardware and more sophisticated build-outs to address any scalability problems we encounter.
Given that basic decision and the architectural pattern goals listed above, we end up with a 10,000 foot architecture diagram that looks something like this:
Next time… We’ll build up the model digging into some of the particular modelling difficulties that come up along the way.
- Danny