I finally have time to work some more on WheelMUD. I'm in the process of implementing the Warrior, Rogue, Mage (WRM) combat system. I'm loading it into WheelMUD's GameSystemController, using MEF. The neat thing about this setup, is that third party developers do not have to worry about plumbing details that much. As long as the correct interfaces are implemented, WheelMUD's MEF implementation will load all the different gaming systems/engines, and game attributes from the game's assembly (coded in any language supported by .NET 4.0).

Here's a screenshot of the console with the custom assembly loaded:

The cool thing about this, is that these custom systems will behave exactly like WheelMUD's internal systems.

I don't have any logic implemented yet, but that is my next step. I'm also looking to see how I can get this thing some unit testing love.

I spent a good amount of time yesterday fixing the Universe Manager Lite (UML). I removed all the stuff that became obsolete when I implemented saving to the document database (RavenDb). I removed races, genders, and alignments. We still have Mud Configuration, Players, and World. Here is how it looks when you load the universe:

Here it is with the area expanded:

I'm planning on adding a new context menu to the room nodes called "Tunneling." I'm hoping that this will make adding rooms a bit more intuitive. I'll add the other nodes, as I learn about how to edit the different types of  MUD content.

I don't have any binaries for this, but the source is available here: svn://svn.wheelmud.net/UniverseManagerLite/trunk

Loading custom game data from the document database is not much harder than saving it. The hardest part has been creating the indexes to retrieve documents. These indexes can be thought as stored procedures. One really nice thing about RavenDb is that it lets you check if these indexes are there, if not, then create them. Here's the code for the index that I'm currently using: 

That DatabaseId is to match the document being saved to the player's settings in the database. It keeps things tidy.

WheelMUD can now save custom gaming data to the document database (RavenDb). This makes it extremely easy to deal with changing requirements for custom gaming systems. There is no relational database schema to fight with. You can pass an object, and it's internal representation will saved as a JSON text document on disk.

I did run into some interesting caveats. You have to be careful in what you try to save. You won't be able to save objects that self-reference. The Thing class had a few properties that were of the Thing type. At first I just tried to decorate these with the JsonIgnore attribute. That didn't quite work in my case, because of how the inheritance chain was setup. I ultimately went with a generic class with all the stuff that I wanted to save. This is now the PlayerDocument class. It makes it very easy to deal with.

This is now working consistently. We have player settings saving to the SQLite database, and gaming data saving to the document database. I really like this hybrid approach as it makes the best use of these two technologies. No more trying to shoehorn a non-relational model onto non-relational data.

Here is the code in WheelMUD.ConnectionStates.CreationState that actually does the saving: 

// Save to the document database

using (var ravenSession = DalUtils.GetRavenSession())

{

    var bundle = new PlayerDocument

        {

            Behaviors = this.Session.Thing.BehaviorManager.ManagedBehaviors,

            DatabaseId = pb.PlayerData.ID,

            Name = newCharacter.Name,

            LastUpdatedDate = currentTime,

            Stats = this.Session.Thing.Stats,

            GameAttributes = this.Session.Thing.SecondaryStats,

            Skills = this.Session.Thing.Skills,

            SubThings = this.Session.Thing.SubThings

        };

    ravenSession.Store(bundle);

    ravenSession.SaveChanges();

}

I made a new class called Gender in the WheelMUD.GameEngine namespace. I always felt uncomfortable with hard-coded genders. I created a data and parser files for Warrior, Rogue, and Mage (WRM). These load into the GameSystemController.Genders dictionary. I thoght this was a more flexible way of doing this. The WRM character creation step that picks genders has been modified to use this new functionality.

My main reason behind this was to support gaming environments that support more than the binary male/female choices. Science fiction has races that have alternate gender arrangements. You have the Andorians in Star Trek that have 4 genders. There are several species in several universes that are hermaphrodites.

While I believe that genders are not necessary for gaming, they do bring interesting prospects for game character development, and can add depth to game play.

Currently the skills are on the Thing class as a list of GameEngine.GameSkill. I keep going back and forth between making skills into a SkillsBehavior or a list of GameSkills. I'm very sure that how to do this will be apparent once we start working on the game basic actions.

The Warrior, Rogue, and Mage (WRM) list of skills are now being loaded into the gaming engine, and are available to the rest of the MUD framework. The WRM character creation system now lets players select their skills. These are now being saved to the document database. I'm working on getting these loading once a player logs back in. Currently stuck on a circular reference loop. 

I'm very excited about this latest bit of code and data that I checked in today. I fixed the stats so that they load a template from whatever gaming system is currently setup to run. First let me enumerate the systems that I tested with today:

• Dungeons and Dragons 4th Edition Quick Start
• GURPS Lite - Generic system, can literally run any genre
• PathFinder - D&D 3rd edition clone
• ShadowRun - Magic and SciFi together
• The Artifact - Science Fiction
• Warrior, Rogue, and Mage - Very simple fantasy system

I got the stats loading for each one. Here are screen captures for each:

Dungeons and Dragons 4th Edition Quick Start

GURPS Lite

PathFinder

ShadowRun 3rd Edition

The Artifact

Warrior, Rogue, and Mage

As you can see, I have the stats for all of these 5 gaming systems loading. It was relatively painless to do this. It took me about 15 minutes per new gaming system to get the stats up and running. Here are the steps:

1. Navigate to the Files\GameRules directory
2. Create a directory to hold your new game system's content
3. Create a Data and Parsers directories under this root directory
4. Create a XML file to hold the stat information, and put it in the Data directory
5. Create a C# parser file, and put it in the Parsers directory
6. Create a master xml file and place it in the Files\GameRules directory
7. Adjust the contents of the master file to point to the root game directory
8. Modify the mud.config file for the new system

Here's a screen capture of the region of the mud.config file that we need to change:

The values above will run The Artifact rules. The most important key here is "masterfile" that will tell WheelMUD which system to pick up. The "currentruleset" value is a human readable label that will be used in WheelMUD for admins and builders.

My main push behind this, is so that I can start figuring out how to do basic combat. I really want to get the core systems working ASAP. I will be moving a lot of stuff off the 0.5 task list, so that we can concentrate on core stuff. The first casualty will be the remote admin stuff. That's just distracting me completing the core systems, which is what we all want to get done.

I've been racking my brain to get Exits to be more programmer friendly. The answer just hit me, and I wanted do a brain dump, so that I don't lose this idea while it is still fresh in my mind.

Here are the two main memes that I had:

• Instead of ExitA and ExitB, rename them to ExitTo and ExitFrom
• Use something like the mediator pattern to deal with things like doors

The first one is so obvious that it gives me physical pain. I have no idea why something so simple didn't surface before. Must be that I was tired every time I looked at this issue. I still think that Foxedup original idea is pretty good, and these semantic changes will make it much easier to deal with.

The second meme is not so easy to explain. I've been studying design patterns in C# for some obstacles and research that I've been doing for the last 3 weeks. The mediator pattern jumped at me, because it could help decouple the doors (and other mud objects) from the exits. I would like to include this logic into the ExitBehavior class in the future.

I think I'm finally getting used to my new work schedule. I hope that I can return to finish coding WheelMUD's 0.5 milestone soon!

 I've been fiddling around with the Behaviors saving and loading using RavenDB. Here's what I learnt... The best strategy is to let RavenDB do what it is good at, which is to store and load documents to/from disk. I was trying to save a dictionary to disk, and running into casting exceptions when converting the dictionary in JSON format to the actual dictionary object. The best strategy, so far, is to save the actual derived Behavior instead. So I've been saving PlayerBehaviors. These load fine, and I don't have to tweak the code to do custom work.

To load the PlayerBehavior documents, I'm issuing this LINQ query:

List<PlayerBehavior> playerBehaviors = session.Query<PlayerBehavior>().ToList();

For saving I'm using this code:

using (var session = DALUtils.GetRavenSession())
{
      session.Store(this);
      session.SaveChanges();
}

    public class DocumentStoreSingleton
    {
        private static EmbeddableDocumentStore _instance;

        public static EmbeddableDocumentStore Instance
        {
            get
            {
                if (_instance == null)
                {
                    _instance = new EmbeddableDocumentStore { DataDirectory = DALUtils.GetDbPath() };
                    _instance.Initialize();
                }

                return _instance;
            }
        }
    }

        public static IDocumentSession GetRavenSession()
        {
            var store = DocumentStoreSingleton.Instance;

            var session = store.OpenSession();

            return session;
        }

The RavenDB team has recommended to make the call to the DocumentStore a singleton. That works well.

I've included a zip with the binaries for this spike. You will be able to create "players" and load them into the UI. You will need .NET 4.0 installed. The source is not ready for distribution, since I would have to copy all the needed assemblies locally.