Historic Forums Archive Notes

[DavidRieman]

Historic Archives

Chronology

WheelMUD has a rich history that goes back to around 1998 (and earliest code I know of, around 1999). Here is a summary, reconstructed from notes in the archived forums that were readily available though. (The forum archives themselves don't go back that far.)

• ~2007: WheelMUD had spent years growing as a functional/playable VB.NET solution. Though it proved VB.NET could pull off a MUD, the limitations of architectural choices meant WheelMUD would best be served by a rewrite. Given that, the opportunity was taken to port to C#.
• July 2007: Fastalanasa was self-hosting dedicated WheelMUD forums, and upgraded them to fresh tech.
• Around 2007: WheelMUD source was housed in Subversion source control, and available via CodePlex.
• March 2008: C# WheelMUD 0.2 milestone source was out (via CodePlex).
• 2010: Lightning strike destroyed a bunch of Fastalanasa's equipment, taking our servers down for a while.
• 2010: David's massive systems re-write merged to the trunk SVN to become the new WheelMUD framework. Request+Commit Eventing and Behavioral Composition become the baseline for working with game entities. MEF non-reboot upgrades are proven viable.
• 2011: WR&M declared the reference gaming system. (Credit to Fastalanasa for finding this system.)
• 2013: Moved to using NuGet references instead of storing binaries for dependencies.

Things We've Tried

Over many years:

• We supported multiple Solution files, to target the differing feature sets of VS products, SharpDevelop, MonoDevelop, etc. Now, we are quite happy to see a single solution for .NET Core working out much better (including good cross-platform supportability).
• WheelMUD has tried a myriad of software development stacks, source management, continuous integration, issue management, and forums technologies. Some examples of tech we no longer use: Subversion, CodePlex, FinalBuild, JIRA, DotNetNuke, CruiseControl (CCNET). Many services were self-hosted for years by Fastalanasa.
• A number of code technologies have been either vetoed or removed, due to various problems. Some examples are C# scripting tech and NVelocity (neither being as debuggable as real C#, and we favor live code updates to cover their use cases), SubSonic, NHibernate, NCalc, and T4 (or other code generation).
• At times we've had WheelMUD.com, WheelMUD.net, and WheelMUD.org registered. (We would probably never pay extortionate fees to domain squatters who immediately take expired domains.)
• We have had stored procedures in the past, but these were phased out (most recently, in favor of adopting document database strategies as the primary storage mechanism).
• We tried having a C# scripting engine in the code, and it was just painful. Instead, we recommend adopting true, debuggable, C# code modules only. (Non-reboot update techniques help fulfill some of the benefits of scripting, while retaining the greater benefits of stable/debuggable/testable coding practices of true code.)
• There used to be a handful of config files to configure different things (like your database connection details and key game options were in different places), and it was confusing/awkward. We've since moved towards having all config stored in a single, self-documenting, App.config.

Archived Forums Content

As a result of the various developer-hosted-and-supported forums getting shuttered over the years (e.g. due to ongoing costs to host and maintain security of custom servers), many thousands of forum posts had been archived in various formats. This content has been rigorously sorted out into three categories: Culled, Summarized, and Preserved content.

Culled Content

Most of the old forums contents were ephemeral (such as troubleshooting, status updates, topics about now-completed plans, or topics which are no longer relevant because the technology we use has changed). Other culled contents were social (holiday greetings or showing off our new rigs or whatnot). Instead of trying to recreate all those old posts into GitHub markdown format and flooding these forums with old info that won't be interesting to newcomers (or worse, might have been actively misleading or confusing), these posts simply won't get brought back online.

Summarized Content

Many posts weren't worth preserving more than an abridged summary, as their value can be preserved succinctly here. Many of these are things we should think about again, but often best to revisit from scratch. Others may be simple to convert to an Issues action item (and then struck from this list). Many were brief ideas which didn't spur full conversation at the time. If you'd like to resurrect any of the following topics, check if there is a related thread already to add on. If not, feel free to create a new thread! (This thread is locked as replies are likely to span too many topics.) A sub-bullet on these lines denotes newer editorial notes.

Summarized Notes:

• Persisting connections across updates can be good. (Hold connections across server reboot?)
  • We have since added some non-reboot update functionality via MEF, and should continue to think about and improve our techniques and documentation here.
• Should think about sockets / connections optimizations.
  • We should devise stress tests and measure first how much a player load we would handle well (versus the most popular existing MUDs).
• (Posted around 2007) InterMUD routers were apparently having severe issues. Dead Souls made a new version.
  • InterMUD is in the roadmap, currently marked as v0.8. We should research and discuss modern options when we get much closer, as well as default channel options (like admin/builder channels for live community support on these topics, but perhaps not player channels by default, due to communication quality concerns).
• Nods to CopySourceAsHtml.
  • No longer as helpful with GitHub markdown.
• Perhaps break down Docs into Dev/Admin/Builder areas.
• Discussion and agreement in 2009 across using "WheelMUD Development Team" wording in more documentation places, new copyright header patterns, and the credits.txt contributor acknowledgement approach.
• A trial with advertising for dev help in 2009 on gamedev brought a handful of short term forums posters, but yielded no long-term developer engagements.
• In February 2014, we experienced an issue with the regular NuGet servers being unreachable (as did others) and thus new devs could not build WheelMUD due to issues entirely outside our control. If this turned into a regular problem, we would want dependencies managed by NuGet for easy updates, but also committed to the repository to guarantee reliability.
• The old, last-working VB.NET version might be still captured on someone's hard-drive or an old source archive somewhere. If found, it would be interesting to ensure it gets its own GitHub repo somewhere for archive/curiosity purposes.
• Command delays (like only being able to use certain skills or skill groups on a cooldown, or maybe all commands) are not present or not functional? Needs further thought?
• Do we still have a small 32x32 gif logo to use in things like CMUD?
• Should revisit what sort of mini-contributions-community we can reinforce (e.g. the "WheelForge" concept, Fastalanasa saw being used for things like: Other-MUD to WheelMUD area converters, Rulesets, SMTP server, FTP server) but could also now be for individual Behaviors, Effects, Commands, etc.
• May want server setup markdown docs talking about optionally setting up the MUD for exposure to online connections (Firewall hints and the like). Be sure to avoid any possible impression that such configuration is necessary for dev work; "Advanced" setup options?
• Revisit item stacking (and should we attempt natural language stuff for it, like "a small blue potion x2" vs "two small blue potions")?
• All existing commands need to be reviewed for "sender.Write" and replaced with Events as appropriate. (Not necessary non-interaction commands like admin commands, and so on?)
• Some MUD protocols to ensure we're tracking: MUD eXtension Protocol (MXP), MUD Sound Protocol (MSP), MUD Client Compression Protocol (MCCP), MUD Mapping Protocol (MMP).
• Ensure "help commands" result same as "commands" command?
• Test and ensure Docs cover proper way to exclude properties from persistence, etc.
• Any way to get RUN-TESTS harness style integration test into CI, perhaps as a long-running Unit Test?
• Check for consistent terminology on Visuals / Fixtures / Furniture (extra details to inspect on rooms and objects...)
• Reference game idea: Passive grouping bonuses from specific character's specialization/skills and such (or leadership levels or something).
• Consider renaming CharacterCreationStateMachineManager to ...Composer? (Do we have similar composition-only classes? Should we?)
• Will MultipleParentsBehavior complicate RavenDB storage?
• Demonstrable damage types, resistances... used in the Reference layers probably? (whether Elements or Unarmed/Blunt/Beam/Psionic/Magic/Etc.)
• Revisit multi-word targeting (like "put big red potion in heavy wooden chest" could either require a combining word like "in" or could actually attempt multiple target validations from "put red potion wooden chest" to see if there is a single viable pairing, and instruct the user to get more specific and use "in" if it couldn't figure it out)? (Came from World Interaction post comments...)
• "get all" / "get all from container" / "get all swords from container" targeting, "drop all" / "drop all swords" targeting...
• Targeting could use near-word correction? E.G. jaro-winkler distance versus each keyword set? (https://stackoverflow.com/questions/19123506/jaro-winkler-distance-algorithm-in-c-sharp%20) (jessemon.blogspot.com/2016/05/comparison-and-review-of-net-fuzzy.html) Help system too, for finding target commands and articles.
• Handling of multiple sensory messages? Rebuild Knock command?
• Behavior for cancelling pick up of things? (CannotCarryBehavior?) e.g. to apply to portals. Or portals could be a furnishing.
• DefaultHelpCommandRenderer needs to print longer, multi-line descriptions for each command. Each command needs these descriptions built in to the code file (perhaps as properties instead of attributes) to help retain parity between the documentation of a given version of the code, with what is coded there.
  • Could also use a "For other commands in this category, type commands [category] and use an MXP link there if MXP enabled.
• Ability to "export" non-command help topics from code, instead of raw loose text files? Same priority system (e.g. to override a default help topic, just export your own with higher priority?)
  • Alternately could be data in the DB, auto-populated by some manner of detecting the topic is missing? Hmm.
  • In-DB would be good especially once we have the in-connection multi-line editor and can use that for admins editing help file data.
  • Consideration of location-specific help topics (like at a complex game table class, though that could also be specific commands of the class.)
• WheelMUD has had a few auxiliary applications, covered separately in Prior Auxiliary Applications #135.

Preserved Content

Other content will be recreated manually into GitHub markdown format for easy reading here on GitHub. Sometimes it will be abridged. Such discussion posts will have a brief standard header linking back to this issue for this context. These posts may or may not include time stamps, and may or may not be anonymized. If the content was something you posted to our WheelMUD forums, and now you've decided you prefer them to be anonymized (or deanonymized): Let me know and I will try to accommodate the request when I can verify your identity as the original poster.

Formatting

I spent a good deal of time thinking about how to format content that was resurrected from our old forums.
I want it to be clear when a given text is being preserved from another writer, even though GitHub marks the post as being written by me.
I think the right tool for this job is "block quotes". A side effect of this is that large swaths (and sometimes almost all of a post) will be inside block quote sections, which look like this:

Block quote section here!

If it's not in a block quote, it's my words: Either it was my turn responding in the original thread, or I've paraphrased parts of the topic, etc.

In many cases, my own responses will be updated to reflect the most modern evolution of the WheelMUD vision and direction.
Since the goal here is to preserve value rather than archiving things just for the sake of archiving them, simply parroting ideas we held then would just add confusion compared to an updated response.
For example, we've switched quite a few key pieces of technology since then.

Closing Notes

My hope is that this archive restoration process will serve as a way to kick-start fresh discussions and ideas on top of what WheelMUD has become today.
Hopefully it will also help spur regeneration of the right kinds of work items in our new GitHub backlog, and accelerate moving more of our designs into design documents in our permanent "docs" folder home.

That said, my time is often limited and of course I have lots of things competing for my time. As usual, I manage to make the most time for WheelMUD while others are also active here.
So this archiving process may continue to be a long-term project, but one I continue to see as one of my core administrative duties as the serving WheelMUD project champion.