Improved Module Composition

[DavidRieman]

(Also related to #121 / #123)

What is our long-term game plan for being a highly composable MUD game system framework that spawns lots of highly customized MUDs in the future? Off-hand, I see multiple ways we could aim for adoption.

One way we can assume will happen is private adoption; copying the source locally, modifying it, and just not contributing anything back to the community. Our license allows this. We don't want to stop you from making a great game just because you don't want to participate in the open community.

One way we can clearly assume will be an adoption angle is GitHub forking. We already have dozens of forks and given our GitHub housing, it's an obvious way to start building your own. We want it to be easy to merge code updates from the framework into your game this way, without having un untenable amount of merge conflicts. So this is a core tenet of our code structuring choices.

Another way we can think about providing in the future is through package management system. Right now we use NuGet packages for our dependencies. It would be a natural progression to some day export individual sections of WheelMUD framework as individual packages. For example, a Core package, one for common Room-Based systems (actions+behaviors), and so on. (And then composite packages as a "starter pack" for particular types of games.) As soon as your server harness references the package, you're basically done: the code will end up in the built directory and our MEF systems will discover the new actions/behaviors/etc. This would not need to replace the GitHub forking strategy, but would be an additional option. One thing that excites me about this is that getting users used to the idea of NuGet packages automatically bringing new functionality into their MUD means it is no big cognitive leap to realize you can put your own NuGet packages up to do the same thing. For example, if you built a cool alternate in-game Auction System, you don't have to convince us to merge it into Core or whatnot - you can put your own package up and share it directly with other game devs. Searching a keyword like "WheelMUD" in NuGet would easily find such modules.

Another: Our previous champion was a proponent for what was essentially our own nesting place for sharable WheelMUD modules from across the community. Doing something like this could be another option, but will take more thought. It may well be that the above modern options have eclipsed most of the original benefits of "rolling our own" that it wouldn't make sense to do this anymore.

[DavidRieman]

RE: Should our modules be smaller (per another thread)?

Yeah, I agree we need to (eventually) break things down further into modules of grouped parts that work well together and should get imported together. (E.G. definition of WorldBehavior, AreaBehavior, RoomBehavior clearly work well together for room-based MUDs but wouldn't need to be imported for coordinate-based MUDs or Roguelike ASCII MUDs, etc.) For now though, I think it makes sense for most of the core Framework to be in a few big modules to be easier for us to work with. We should put "improved modularization" on the road map though and open [this thread]. (Community module creation and sharing has also always been a big part of the long-term WheelMUD game plan.)