Which Reference Implementations?

[DavidRieman]

(Discussion for #119, and relates to #121.)

In 2011, "Warrior, Rogue & Mage" was chosen as a game system to target for building our first Reference Implementation. WR&M was chosen largely for being a free open system, and the simplicity of it (collapsing what are traditionally thought of as "classes" down to being just 3 stats of the character).

This reference implementation fell apart when we upgraded .NET version, and the library we leaned on for stat management / rule sets / dynamic calculations and such was found not to be well used, did not upgrade well, housed multiple major problems that would lead to game-breaking problems, and no longer appears to have any sort of maintained online presence as a technology. So those aspects of WR&M got ripped out to complete the upgrade, and our current state of WR&M is pretty broken, to the point that I think it's worth reassessing whether it's a solid choice still.

Personally, I've grown to dislike that our fantasy world "reference" would be blending the notion of what is traditionally thought of as Classes with what we codify as Stats/Attributes. While the system is neat/novel, it carries a cognitive cost that those assessing our framework will have to work through. So I don't think it's a good reference implementation compared to the option of, say, having a more traditional Class/Level/Stats arrangement that won't require some sort of walk-through to introduce you to the aspects of the reference implementation that don't make sense for your traditional popular fantasy MUD.

So the question is, would anyone object to dropping WR&M as a reference implementation? I think we're free to redefine what we think will be a good collection of long-term target Reference Implementations. Currently, this is what I see, maybe even using these terms:

Social Reference MUD:

• Communications focused. Players can talk directly to each other, read/write to message boards, and use chat channels.
• No rooms. Excludes any room-based Core commands at startup, excludes OlC support, etc.
• No player inventories, player advancement, combat, etc. Culls such categories of Core commands as well.
• Ought to be our slimmest, and easiest to build reference implementation due to the limited feature set.

Fantasy Reference Game:

• Traditional but limited fantasy world. Comes with a newbie walkthrough area and starter zone.
• World is seeded from a known set of designed rooms, but includes demonstrable OlC.
• Typical tick-based combat pacing.
• Very limited classes, spells, and so on, for v1. Maybe we keep the classes to Warrior, Rogue, and Mage as a nod to the system.
• Very few stats/attributes (maybe just "mind/body", "hp/mana") for v1.

Space Reference Game:

• Our opportunity to demonstrate wildly different type of gameplay than traditional fantasy MUDs.
• Basic, but procedurally-generated universe seeded initially with randomly named systems/planets/stations, and basic trading economy. World can generate systems at universe fringe at admin's command.
• Mostly no "rooms" - Time-based, coordinate-based travel determined by ship capabilities and scanned/discovered places.
• OlC for designing ships, stations, and so on as basis for randomly generated world and NPC usage, rather than defining an exact world itself. But also to adjust the procedurally-generated world's details.
• Players usually command ships, big ships can house small ships (players saving docked in other players).
• Semi-turn-based or other combat system that differs greatly from tick-based combat pacing. (Perhaps range-sensitive combat with actions reminiscent to "controlling a bridge" with routing shields power, reconfiguring weapons arrays, and so on? TBD later.)

Those even progress in order of difficulty and further test and exercise the flexibility of the Core systems we have to get in place for each. So we could focus on Social, polish it quite a bit, and then maintain it as we focus on Fantasy, etc. How do we feel about these as high-level target reference implementations to build and support?

(Obviously we hope others will take our framework and build additional detailed systems, much like how traditional MUD code bases have popular "flavors" that grow and evolve. Hopefully this growth will occur in a healthy way for two-way merges of core functionality, such as being based on GitHub forks. We'll discuss how to promote and maintain that health in another discussion topic.)

[ghost]

I feel it would be more beneficial to break things down into smaller more focused modules. For example(Combat, Trading, Chat, Vehicles, Vendors, Etc.) This allows the community to create small niche modules that can be easily downloaded by others to use or to see an example of code on how to implement the same feature in their game.

[DavidRieman]

EDIT: Moved part to #125

For this thread though, I want to focus on (whether and) which Reference Implementations we should line up as the most helpful to us. IMO it's very helpful to be building reference implementations. Without doing so, we're just trying to build isolated pieces of code that we hope will work when combined out in the wild. For example, we built ExitBehavior in a way that we believe we could just omit the class entirely and easily for a MUD which doesn't need "exits" without having to refactor the framework itself, and it "should just work" to do so. But until we actually try it both ways, it's really difficult to be confident that we met those goals. Does it work well with the classes it typically works with, like OpensClosesBehavior and then LocksUnlocksBehavior for a locking door? These classes all do have to be built with each other in mind to design the right way for them to isolate their code yet work well together. If we never integrated it all together, we'd have no way to know if we nailed it.

If and when we get to building a non-room-based reference game, the goal there is to prove that our framework is as flexible as we think it is; finding and fixing all the hidden remaining pain points in the framework that work against that goal. Things like Actions that inadvertently assumed a room-based MUD when reading a Thing's Parent, and instead need to be revised to be less dependent on such things, etc.

We also want potential new devs to have a rich experience by default the first time they pull down and launch our code, without having to jump through a bunch of hoops. The "First Launch Experience" needs to be a "Wow, this is really advanced!" moment to captivate contributors and built momentum.