Mud Designer's first real sprint

Now that I have Mud Designer moved over to Visual Studio Online (VSO) I can start really making use of the Agile platform that VSO is built on top of. Going forward, the project will adopt the Agile methodology, with developing taking place during sprints.

The first sprint started today with three User Stories being brought in to the sprint.

  • Text File Data Storage Service
  • Character Security Permissions
  • Command Security

Text File Data Storage Service

Once this is completed, I will have the first of many data storage services created. The intent is to create a simple data store to use while I build the rest of the engine. I have other Stories for creating SQL and Cloud based services, but those are more complex. While the engine is being developed, I want to just use a simple local data store.

Character Security Permissions

This story contains the meat of the engines security framework. When completed, Permissions can be created and assigned to Roles. There will be a framework constructed for objects that need specific security permissions, to register for them.

Command Security

Pigging backing on top of the Character Security Permissions story, this will allow Commands to register for permissions they require. The engine will ensure that users have the required permissions within their roles before letting them execute the command.

Wrapping up

Since I am the only developer, each sprint is scheduled for 4 weeks, so it will be a bit before this sprint is completed. If the user stories are finished early, I will pull more stories in and continue working until the end of the sprint.

As each story is completed, I plan on writing a post on what work was done and what the features are. I would also like to do a code analysis and report the quality of the code for each story.

Mud Designer Migrated to Git

I have been really wanting to use the Visual Studio Online (VSO) service for a while now with Mud Designer. I have been holding back primarily because Mud Designer is open source, while VSO is meant for closed-source team projects. TFS doesn't come with an easy way of maintaining two repositories of the same code-base, while maintaining the version history of the source.

The solution to this was Git, but the Codeplex project was hosted on a TFS instance. I then discovered - (thanks to Richard Banks for answering my Stackoverflow post) - that the Codeplex team could convert my project to a Git repository. I promptly fired them an e-mail and had my project converted.

Now that Mud Designer was sitting in a Git project, I cloned it to VSO. Now any time I push changes to VSO, I can simultaneously push changes to Codeplex. This lets me make use of VSO's Agile work items, such as User Stories, sprints and bug tracking, while keeping the source freely available to the public. Win win!

Relative size of a possible 13" iPad

Since there are rumors still going around of a possible 13" iPad Air, I thought a picture showing a 13" Surface Pro 3 would help give some perspective.

In the photo, from bottom to top, is a Microsoft Surface Pro 3, an iPad Air, an iPad mini, an iPhone 6 Plus, iPhone 6 and an iPhone 5.

Mud Designer Architecture

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.