Improved Reference Implementations Handling

[DavidRieman]

(Discussion for #119, and relates to #123)

Terminology:

• "WheelMUD Framework" or "WheelMUD Core" - The highly-reusable components that help you to build the MUD of your dreams, whatever that is.
• "Reference Implementation" - A light, actual game built on top of the WheelMUD Framework, whose purpose is to be a "reference material" for how one goes about building their own MUD in a way that plays to the WheelMUD Framework's strengths. It is not necessarily mean to be a complete, fun game, but is meant to demonstrate how one would get there.

Right now, if we open the WheelMUD.sln and run the "ServerHarness", what that is actually configured to run is the "WarriorRogueMage" reference implementation of WheelMUD.

There are a couple problems with this approach that we want to address:

• It is not immediately clear that WR&M is merely one reference implementation, and that WheelMUD is not remotely defined by the confines of this game system.
• The way we find and link our libraries is very powerful and dynamic, but leads to a situation where you can make a change and run the ServerHarness, and you won't see your changes because the game system libraries itself are not a hard project dependency of ServerHarness.

Some ways we might address these issues, we can discuss by name:

• Reference Repositories: Move reference implementations like WR&M out to their own repositories.
• Multiple ServerHarnesses: Have multiple versions of ServerHarness, which could take on names for their reference implementation.
• Configuration Manager: Lean on the Visual Studio Configuration selection to designate which Reference Implementation is being used by ServerHarness.
• Other ideas?

[ghost]

This looks like a great start!

My thoughts on all the points mentioned;

I prefer 'Framework' over 'Core'.

I like the idea of moving WR&M to a repository labeled something like 'Example Modules' where you can drop recyclable modules like WR&M in so people can pick and choose what modules they would like to use.

• All for Reference Repositories!
• Multiple ServerHarnesses seems like it could be an unneeded pain when you can let the core handle underlying server stuff.
• Configuration manager, I'd say use a custom script for this and do not rely on MS, as not everyone uses VS. I use Rider for example.
• Another option is to create a 'Modules' folder where a config script searches through the directory and loads each module within.

[DavidRieman]

I was thinking any one of the 3 ways could address the listed problems; hope I didn't come across as recommending we do all 3.

custom script

If you're talking about shell scripts for building, this is really hard to do well in a cross-platform way, and increases dependencies and can compromise the "First Launch Experience".

do not rely on MS, as not everyone uses VS

I believe the solution is currently buildable without Visual Studio, with a single command from the command line. I haven't done that myself lately though. Current configuration options (like "debug" and "release" options) can of course be specified from command-line, as would new options like "debug-social" or "release-fantasy" options for the Configuration Manager approach.

'Modules' folder where a config script searches

Not quite sure what you mean here. Modifying MEF to search by directory from some app.config entries or something defining which of a bunch of modules it should be allowed to discover?

Some pros/cons for each:

Reference Repositories Pros:

• Strong fracture line proving boundaries between game and framework.

Reference Repositories Cons:

• Harder to make one framework change and test it on all reference implementations.
• More repositories to maintain.
• More education of all the repositories a newcomer probably cares about, and links to follow back to main repo.
• More work for visitors to check out and explore all the reference implementations in direct comparison.
• Less self-documenting usage examples of a given piece of code in the main core repository.
• Devs have more studying and choices to make before forking.
• Likely incurs additional integration steps in both directions to flow code improvements.

Multiple ServerHarnesses Pros:

• Easy to discover and test each one out, by just setting start-up project and run.
• Definitely easy to get project references to be understood at build time (and strong Browse To Definition capabilities as nothing fancy is going on).

Multiple ServerHarnesses Cons:

• Not sure if we can easily enforce which one is "default".
• Solution is a bit bigger (but we could compensate with smart foldering).
• Possibly hard to guarantee which ServerHarness is the default "Startup Project" upon first solution launch.

Configuration Manager Pros:

• Easy to discover and test each one out, by just setting config option and run.
• Probably able to convince project references to be understood at build time.

Configuration Manager Cons:

• May be hard to define conditional references with this approach; Probably possible but probably awkward.
• Possible combinatorial explosion between true configurations (debug/release; suppose we added one in between for performance measurements), versus reference game.
• Possibly hard to guarantee which option is selected by default upon first solution launch.

And I forgot another option:
Multiple Solutions Pros:

• Easy to discover and test each one out, by just launching the applicable solution.
• Would be able to get project references to be well understood at built time, if each solution also held its own variant of ServerHarness.

Multiple Solutions Cons:

• Maintenance of multiple solutions can be annoying; refactoring into new lib boundaries and such is a bit more work. We'd mitigate by ensuring automatic CI across all solutions though (which wasn't an option last time we had pains from multiple solutions).

Any approach may need at least small updates to the quick-start dev documentation to explain.

As multiple approaches talk of customizing ServerHarness, note we could better abstract it so that the bulk of code/work is in one library, and the actual executable project itself would just reference that shared library and the applicable game-specific set of libraries it wants to enforce getting copied to the built binaries, for MEF to discover.

[ghost]

I'll add another con to the list to consider. Having a larger initial repo makes updating use more bandwidth and storage space. Although most won't notice much of a difference, for some every bit counts (school campuses, some isp's, some hosting providers).

[ghost]

An ideal solution would be one that the core can be updated in place without affecting the modules. Obviously this would be for small security updates and such, as major updates might require modules to be updated as well.

[DavidRieman]

Indeed, consuming WheelMUD as a set of smaller modules could be beneficial for those who want the ability to takes updates to some of their WM dependencies without updating all of their WM dependencies at the same time. (Which can help adopt any breaking changes one bite at a time.) One way to support this strategy is proposed at #125. Fortunately, none of the strategies above for handling how we compartmentalize reference implementations code would have undue impact on doing something like publishing WheelMUD modules as a bunch of small NuGet packages.

[DavidRieman]

I'm leaning towards Multiple ServerHarnesses, with most of the existing ServerHarness logic moving to a shared library or whatnot for minimal code duplication between them. Once done, we'll want the documentation updated to make it obvious how to select the startup project and test out the different reference game implementations.