It seems like you're really getting into it again. That's good to see.

Sounds like it's worth a look. I don't have any experience with MEF, nor DI frameworks in general (which it looks like this is sort of related?) - but maybe something like this would even help to get things like the Actions to be unloadable/reloadable too. :)

Well, MEF is actually a plug-in system that is supposed to be baked into .NET 4.0. Not sure why people keep thinking that MEF is a DI container. I noticed a lot of people in the MEF forums confusing it with Microsoft's Unity, which is a DI container.

Ya a quick perusal of the overview / intro pages and some of the comments gave me that impression. Personally, I'd have to go learn a lot more on these subjects before I cuold give a valuable opinion of MEF.

I hear ya. I'm looking at that TreeTrim project I linked to earlier in the thread. I was able to find out how MEF works, at least up to the plugin/part discovery code. The TreeTrim project code is a lot cleaner than I expected. Thankfully, it is not doing anything too complicated, so I can follow along.

I added a new interface and enum to help us along: IDiscoverableMUDSystem and DiscoverableMudSystemType.

Hi all,

I am having a look at using MEF to allow the character creation process to be pluggable. I don't see any technical issues with doing it - it's a simple scenario for MEF - it can load the plugins from one or more .dlls in a folder of our choice.

What I would like a few opinions on, however, is the contract of the plugins - especially when talking about moving from state to state.

User Stories:
> A creator should be able to add a step to the end of the process because their rule-set has extra character creation steps.
> A creator should be able to insert a step in the middle of the process because their rule-set needs to have a character creation step occur before an existing step.
> A creator should be able to reorder the existing steps because their ordering preferences are different.
> A creator should be able to remove a step because their rule-set does not cover an existing creation step.

Acceptance Criteria:
> Steps may have prerequisites that must be observed.

After thinking about it a while, I believe that we should:
a) Plug-in the steps, giving each a name.
b) Plug-in a class that will manage the order the steps should be executed in, finding each by name.

I'm very interested in other people's opinions.

Sounds like an interesting and reasonable approach.

Ideally each step would also be pretty flexible, from a data-driven angle; for example a "choose a race" step would use a list of races that comes from the DB, race description and listed racial modifiers and such would also come from the DB, etc... thus requiring little or no code change for a particular MUD's set of races.

A generic stat selection module or two could exist as defaults, but often a rule-set distribution might include a stat selection module, as some may have a very specific "point buy" system or "roll, reroll, assign" types of processes and would be hard (and bad) to make such logic completely data-driven. An admin who wants to roll their own stat selection step would build one that's exposed to this plug-in system, give it a unique name, and point the manager data to their own stat selection step instead of any others.

Ya, personally I like where this could go.

This is looking quite good, so far.

I'm proposing that we use the ruleset master document to point the plugin discovery code to a specific folder where they system can find all the assemblies that need to be loaded for the specific ruleset. I already do this for auto-discovering gaming tables and their parsers.

Good points all round.

@Karak
Sounds very sensible to me: The default race-select step may be generic enough to be just data-driven, but we can assume other steps will probably require their own plugins. Would it be wise to offer some richer options during the race-select, e.g. preview racial description before picking? [That would be one to look at after committing the general MEF structure!]

@Fastalanasa
I shall ensure that it picks up the plugins directory from the ruleset master.

I should be creating a branch tonight when I may be able to commit an initial (unpolished) version.

Thanks!

Interesting scenario that I didn't think of before:

User Story
> A creator should be able to add a step that can navigate to different steps depending on the result. This is because character creation will not always be linear, e.g. a password is incorrectly confirmed and must re-enter their original choice.

Makes it a little more complicated ;)

I've got a working version of the plugin system working in the MEFCharacterCreation branch.

It's not finished - I have not yet tied it into the ruleset master, as well as needing some refactoring and commenting.

The character-creation process should act the same as it did before, but the order of the steps (and what steps are used) are actually determined at run-time.

I shall add a new 'test' step to ensure we can add extras, then finish off the last few changes.

Opinions very welcome!

Refactored and ready for review :)

It's tied into the rule master, and I've extended the XML parsing to allow you to configure any number of plugin folders.

Thanks to everyone for the input into the design.

Awesome! I was able to only look it over a bit. My wife broke her ankle yesterday, and the means that I can finish the DAL refactor or review your code, but not both. Hey Foxedup and Karak, do you guys mind doing a review of his code?

Question for the group...

There are usually 2 types of approach for plugins.

1) Have a shell, and load the innards through the plugin system

2) Load the whole system as a plugin.

Do we want to use both approaches, or just one?

> A creator should be able to add a step that can navigate to different steps depending on the result. This is because character creation will not always be linear, e.g. a password is incorrectly confirmed and must re-enter their original choice.

Maybe the password verification should be part of the password entry state anyway. Although, I can see non-linearity in a custom "confirm or revise" state where you can review the results of the previous steps just before finalizing, and going back and redoing a given step that you changed your mind on. Not critical, but probably a good user experience to support the ability to do something like that.

> My wife broke her ankle yesterday
Sorry to hear that :(

> Karak, do you guys mind doing a review
I'd like to, but i've also had very little time lately - didn't end up having time to even debug the DB issues I was having. I'll try to find some time in the next few days but no guarantees yet.

> Do we want to use both approaches, or just one
*shrug* I'm not sure I see any critical differences between the approaches. If I understand, Nos' work applies one of these to char creation?

@Fastalanasa
Eek - I hope she's okay!

@Karak
Essentially, there are two plugged-in components to the plugin system:
1) A set of steps, loaded in by MEF into the handler
2) A state-machine, whose job it is to control what step is called, depending on the pass/fail state of the previous step. This too is loaded in by MEF.

Overall, the system is in the first outlined approach. The state-machine means that the steps do not need to have any knowledge of any other step in the system. It is also trivially easy to reorder them.

To work with your "confirm or revise" situation, I could easily adapt it to pass a dictionary/hashtable to each step, where they can add information to it, or check for something added by someone else.

e.g. when selecting a race, you add it to this hashtable:
context["race"] = "giant"

...and it can be confirmed in another step:

Confirm("You have chosen the " + ( context["race"] ?? "unknown" ) + " race. Are you sure?")

It wouldn't take long to add if you think it might be beneficial.

Nostradamus,

Could you merge your changes into the trunk after we get 0.3 out the door?

One of the things that nobody has answered for me is about the feasibility of discovering whole MUD systems through the MEF mechanism. RuleSets are not going to cover all of the cases, and any system depending on the specific game rules will need to be custom coded to the rules. The best way of dealing with those are to load them through the MEF discovery mechanism, so that admins only have to point to the gaming system master document, and our engine will do the rest. That's why I put in IDiscoverableSystem interface.

Hi Fastalanasa,

I would be more than happy to merge the changes in after you give me the say-so :)

With regards to MEF's feasibility for a MUD-wide system, I believe it could function. I'm not able to say for certain whether your IDiscoverableSystem will work with it (not by default - throws an exception when there is more than one plugin for an interface unless you hold an array/collection of them), but I believe some advanced scenarios may allow us to determine how it matches which plugins to use. I will do some more research - the plugin system for character creation was quite simple.

I will get back to you after I've had a look around!