Mud Designer Architecture

in ,

I had a bit of free time tonight, so I thought I would put together a quick post on how the overall engine architecture now looks. The following is a diagram showing the engine's major layers.

As shown in the diagram, the application is broken up in to three major layers, not including the apps.

Engine

The Engine layer being the base layer that everything is built on top of and relies on. The engine has a Core project, that is a portable class library. This project contains all of the Types that can be shared across all platforms, including Windows 7, Windows 8, Windows 8 Metro, Windows Phone 8, iOS, Android, Linux and OS X.

The Desktop application project holds the Types that can be shared across desktop applications, with the goal being Windows 7, Windows 8 desktop, Linux and OS X.

The Networking.Portable will eventually be renamed to Default.Mobile, and that will contain Types specific to mobile devices like Windows 8 metro, Windows Phone 8, iOS and Android.

The bulk of the code will be usable across all platforms, which was the biggest challenge. Since I don't have Xamarin licenses, I can't do any testing to see if the code runs as expected on iOS & Android. I should be able to start running tests in OS X over the next month.

Windows Desktop App

This layer is composed of several projects that ultimately make up the Windows Desktop version of the editing tools & server. The actual app will reference an Infrastructure project, which will contain support Types and region definitions. A region is a part of the user interface that can hold a module and ultimately provide support for 3rd party plugins. An example of a region would be that of a menu region, content region or a toolbox region. Regions provide an easy way for 3rd party developers to create modules that plug in to the editor, in the area that they feel it needs to be installed to, with ease.

A modules project is actually another layer by itself, that sits as part of the overall app. There can be an unlimited number of module projects, each providing the actual Views and view models that the app will use. It provides support for 3rd party modules that can be plugged in to the editor at run-time. Modules are used by the editor to provide tools to the end-user for creating their game. Modules are not referenced by anything, allowing them to be freely added and removed without needing to rebuild the toolkit. The modules themselves only reference the infrastructure and shared windows library.

Both the Infrastructure and Modules projects reference a Windows Shared Library project. This project will contain code that can be shared across multiple Windows Desktop apps. Such as the Server, the Editor and a future Web-App. This will contain things such as support classes, Factories and any Facade's that can be shared.

Shared Windows Library

The Shared Windows Library will contain the code needed to set up all of the dependency's, determine what repositories and services are needed and expose them through an interface to the apps. Mostly via Factories.

Windows store Apps

This layer provides the code-base for the Windows metro styled apps. These will require their own views and view models, but should be able to share the same factories and repositories.

Repository

The Repository layer is used to bridge the gap between the App and the data storage medium. There will be two different ways to retrieve objects within the app.

  1. Create a new instance using a Factory in the the Windows Shared Library
  2. Fetch existing objects using a Repository.

The Repository will let the app restore, save and delete objects without the app needing to know what the storage medium is. You can easily replace the default storage mediums with something custom if you want, such as some kind of cloud hosting. The overall framework won't really need to know. There is some set-up that must be done to facilitate this, but that is pretty straight forward and will be saved for another post.

Since the data store is often times platform specific, Repositories provide the app and engine a cross-platform solution to accessing data. They don't need to know what platform they are running on, or where the data is stored. You can also intermix data stores, such as saving player data locally in encrypted files and hosting your world data in the cloud. The repositories take care of putting it all back together.

Repositories are also used for data caching. If one object asks a repository to fetch a collection of every Room in the game, the repository will cache the data fetched from the storage service. The next object that asks for a one or many rooms, will be provided an instance that was previously cached. This saves trips to the data storage, which is often times expensive from a performance stand-point to do.

Note that a Desktop and a Portable Repository project is shown only to demonstrate that you could have a repository per platform if needed. Since different platforms might require different caching techniques. When the engine ships, the goal is to only ship a Repository layer that is not broken down in to Desktop and Portable. I want that to take place at the Service layer and allow the engine and all apps to share the same Repositories.

Services

While the Repostories are meant to let objects access data without knowing where it is stored, the Services layer must communicate directly with the stored data. This layer is what performs the communication with any storage servers, deserialization of xml files, encryption and data transformation. An object can be transformed to fit in to a specific data structure for saving, and then transformed back in to the object it came from when loaded later.

Finally

This set up has provided the engine with a nice level of abstraction and layering. All of the core components in each layer are hidden behind interfaces, so 3rd party developers may customize or replace pieces within each layer as needed.

This post only showed the Windows Apps. Adding other platforms would only require a new project for each platform, such as OS X, with views, view models and any platform specific support. Once the overall product is finished, adding support for other platforms should be a relatively simple endeavor.

In a future post, I will break each layer down - once a bit more of the framework is completed - and review them in a bit more detail. More and likely one post per layer.