The Hub Concept: Structured Mush Development

Selerik

Laying out this idea below. It has been kicking around in my head for years, I've had plenty of talks with others that went nowhere. I'm not expecting anyone to pick this up and run with it. I just want to write it out once in full and really look at it with the eyes of other developers on it too.

Core Concept
Too many games rebuild the wheel. Efforts to improve organization are happening in bits and pieces over time, and coming up with a community structure for support, a set of guard rails, can mitigate a lot of the pitfalls I've seen.

The design below would mimic some of the elements of the more successful mod communities, and acknowledges that the desire to contribute to a game does not mean you have the full package of skills to do so: Management, Community Development, Relevant Coding Experience, Storytelling, Worldbuilding, Time Management... It is rare to find that team which brings everything to the table. Most of the time we struggle on something that can't be unmanaged, and it detracts from the stuff we're really good at.

This doesn't specify a backend, I know both Ares and Evennia are already setup to do some of these things. Various other tools exist that can do other parts. This is more about a structure

Lexicon of Terms
Because it helps to use consistent language

User Terms

Account: The core credential for access. All users are required to have an account in order to connect to anything in the network.
Account Login: Entering Account credentials in order to access some part of the Hub network.
Account Permissions: Your special credentials on your account. Relevant only to Repository and Hub administrators.
Profile: Profiles are created on individual Hubs. Profiles have names unique ot that hub,. and are associated with your Account automatically.
Profile Login: After performing Account Login on a Hub, you are allowed to select one of your profiles or create a new one. Simple click through.
Profile Permissions: Your special credentials on a profile. Unique to that profile on that Hub.

Architecture Terms

Hub: An individual server supporting multiple games.
Hub Network: All currently active Hubs.
Spoke: Name taken from the spokes of a wheel. An individual game world hosted on a system hub.
The Repository: The development and support website. Includes some core backend services, such as the accounts database.

The Repository
The Repository is not an actual MU.
It is a website with a database and account system.
The Repository provides resources for all users as detailed below.

Hub Tracker
The Hub Tracker is a publicly visible dashboard with information pertaining to the Hub network.
- Visible without login, mobile friendly.
- Any active Hub automatically reports use data back to the Hub Tracker.
  - Usage statistics only, no individual user data of any kind.
- Consists of three key views: Hub List, Hub Details, Bounty Page.
- Hub List
  - Serves as a public advertisement for all hub servers.
  - Reports uptime.
    - Server uptime, average uptime over past 30 days, current status, etc.
  - Reports users.
    - Average users connected, Peak users connected in past 30 days, current users connected, etc.
- Hub Details
  - Click through information on a particular hub.
  - Includes a click through to the hub and a brief advertisement.
    - If not logged in, click through prompts to login or create an account first.
  - Includes a report on the spokes on that Hub.
    - Names of individual spokes, average user data as subset of user report.
  - Includes module use statistics on that Hub.
    - List of installed modules with versions, associated code use statistics as appropriate.
- Bounty Page
  - List of desired code improvements from users in the community.
  - Connected users may flag an individual bounty as important, raising their visibility.
  - Bounties are satisfied by identifying code in the repository that can do what is requested, whether old or a new submission.
  - No monetary reward component.
    - It'd be nice to pay our coders but I would need a contract lawyer to vet that.

Modular Development Standards
- All code must either work by itself, or clearly identify the dependencies that must be met for it to work
- Relevant guidelines for code development provided
- Dependencies of all modules defined within the code itself
  - Enables internal check to ensure dependencies are met before module is loaded
- Installed modules and their versions reported to Hub Tracker
  - Configurations of modules not reported

Code Archive
Where the code lives when you aren't using it
- Uniform naming conventions.
- Submission guidelines provided.
- Standard submission format.
- Versioning enforced.
- Submission dates documented.
- Baked in credit to the developer(s).
- Licensing agreement defined at time of submission.
  - Declares that the code is their own work.
  - Permits community use of the code so long as that use is not for direct profit.
    - Having a patreon is okay, requiring users pay to play is a violation.
  - Permit other users to create modules that use this work as a dependency.
- Searchable by all users.

Hub Launch Process
Information needed to create a new Hub and integrate it into the Hub Network.
- Repository support provided at no charge
  - Limited to login support, module downloads, and the Hub Tracker reports
  - Not that donations would be a bad thing
- Hosting options out of scope
  - Let the people specialized in hosting do what they do best

Hub Owner Control Panel
Make adding, updating, and removing modules easy
- GUI page associated with the account owner for a Hub
- Provides the module information from the Hub Details page with admin buttons
  - Lists warnings when updated versions of installed modules exist
  - Can enable, disable, update, or remove any module via button click with confirmation
  - Allows lookup of new modules by name to flag for installation
- Provides the spoke information from the Hub Details page with admin buttons
  - Can create new spokes, alter their names on the Hub Tracker, or delete them entirely.
    - List of profiles associated with each spoke, this is queried from the Hub itself and not stored on the Repository. Only visible to the Hub Owner.

Individual Game Hub
This is a server you can connect to and play on. Functionally accessed just like any other mush.
Naming convention for a hub will be 'Hub (Number in order of hubs created) - <Game System Supported>.
Ex: Hub #1 - Dungeons & Dragons 2nd Edition.
Hubs with original games will be asked to name the mechanics system supporting their game distinctly from their story or worlds.

Account and Profile Driven
Support for associating multiple characters on multiple games with single user account. Ares does this, no longer a novel idea.
- Secure Login: All logins managed by the Repository with validation reported to the Hub.
- Hub Owner: The person who oversees the hub and pays to keep the lights on.
  - Full system access.
  - The only Account with special permissions on the Repository.
- Hub Development Staff: Coders who have demonstrated their competency and are trusted to review and post changes independently of the Hub Owner.
  - Full code access on the Hub..
- Hub Support Staff: Community support roles unrelated to a specific game. Expected to maintain neutrality when acting in this capacity.
  - Ability to ban or restrict access for player accounts and IPs.
- Spoke Owner: The lead for a specific game on this hub. They control all story, house rules, and related decisions.
  - Control all game specific decisions, including character approvals.
  - May ban players from their game, but not from the server.
  - May add/remove staff from their game and share permissions with those staff as they see fit.
- Spoke Staff: Game-specific staff. Storytellers and related.
  - Duties and authority as defined by the Spoke Owner.
- Character: Individual character you can play as.
  - Associated with a particular Spoke and approved by that Spoke's Staff.
  - Uses the commands as configured for the spoke(s) they have access to.
    - One-to-many situations covered in Collaboration support.

Dedicated to a Game System, not a Game
The goal is to provide all of the foundational code support needed for the game system in a single place, then allow people to engage in world building.
- Spoke Independence - The Hub supports the code that enables playing the game. Spokes pick their own stories and can modify the rules as they see fit.
- Shared Commons - A development and community space independent of the existing game worlds supported, available to all users.
- Association Flags - Rooms, Profiles Assets on a server may be associated with one or more Spokes. This restricts access to being only for those Spokes.
  - This enables secret societies and similar within a game, by having a spoke within a spoke. Spokes all the way down.
- Collaboration Support - Two or more Spokes in a Hub can choose to collaborate on a wider story.
  - Profiles allowed to have multiple spoke permissions.
    - Disambiguation support for profiles with multiple spoke permissions, to avoid running the same command against multiple spokes with different customizations.
    - Ability to designate default profile for running code.
    - Ability to transfer characters between spokes, pending approval by Spoke staff.
      - Depending on spoke customizations, this might not work smoothly.
  - Ability to create collaboration spokes
    - Explicitly possible due to Association Flags

So there it is. The concepts I combined are all pretty generic, and not at all unique to programming or game development. The segregation of duties by specialty while reducing how much individual games live in silos was the idea, but with Github and similar resources being so popular today the value is far reduced from where it was ten years ago. I know some parts are more practical than others, but maybe the bits still impractical today will be solved within a few years by other developments.

Thanks for reading.

Bananerz

I like the above!

In the MU community: I'd say that out of the MU things I've interacted with, Ares seems to be close to what you're describing. @faraday has really done well, and the website, forum and discord really build on that hub and spoke feel. You're a player who can float across multiple games.

Outside the MU community: This reminds me of Fantasy Groups and Roll20 except for the Modules, Code. They're generally game system agnostic, in that multiple different types of systems can be incorporated on the core service and repository. They provide (again generally) support for Windows, Mac, Linux and/or online.

Ghost

@Selerik Feedback. Great idea.

Using coordinated efforts (such as those provided by Git) other open source software has been shown to vastly improve and address known flaws/vulnerabilities. A coordinated approach towards MU code as Open Source Software (which it is, mostly) could result in better standards, cleaner code, and churn out better administration (as well as swappable talent).

Using the concept that "more eyes can see more flaws" (or whatever that security principle was. Kerchoff?) the code being out in the open for review and coordination makes it more likely that anything malicious will be spotted. A lot of MU code hasn't updated at the base level in decades, too, so continued development will do it well.

I've always thought these silo'd efforts between Devs has been great for specific code based, but ultimately using up good time that could have been spent building as a community.

faraday

Interesting idea, though I think some of the terminology runs contrary to what MUs already use so I'm not sure how the various pieces correspond to MUSHes - what's a hub, what's a repository, etc.

MUSHes notably don't have an overarching "account" concept. Even the Ares player handle accounts are linked to your characters; you don't use it when logging into individual games.

Selerik

@faraday The proposal related to accounts has a few reasons behind it. Some are structural, some are cultural. I'll start with the cultural.

First, it builds an investment in the community over time and with that a sense of responsibility. While some users will put their best foot forward by nature, others see the typical anonymity of the internet as a means to engage in harmful behaviors.

Even if you yourself engage in good behaviors, and mostly engage with people using good behaviors, you might suffer a distrust of others due to the bad experiences with a select few. Particularly the new or unfamiliar. This isn't unique to mushing, it is a behavior pattern visible all throughout internet culture. If you get an invite from a Facebook account made last week, you probably aren't going to assume it is some new user who just discovered the platform and happened to want to connect. We've seen this whack-a-mole happen recently over on Arx, with the 'Is-it-so-and-so-again?' conversation coming to the Hog Pit like the regularly scheduled resurgence of the McRib.

You even see this behavior in video games, with VAC bans and the toxic player checks in most of esports. When a reputation in the community is built up not just at one game, but across multiple over time, you will be left with a more genuine sense of who you're dealing with than what we're normally permitted.

Moving to the consideration of structure, having account logins not managed locally enables a consistent login credential across games. You can add it to a credential wallet, you can more easily setup MFA support, you can associate persistent information should the community expand to benefit from it later. Maybe recognition of coding talent or awards related to player satisfaction for plots you've administered will eventually become a highlight. Maybe there'll be some sort of kudos system, where other accounts can recognize you as an awesome person. Maybe we'll get that bounty system vetted by a lawyer-accountant-lizard-person-scientologist, and suddenly have a way to properly manage rewarding coders with money for their freelance work. Who knows.

Derp

I mean, some of this is stuff that used to exist once upon a time ago, and was abandoned for specific and various reasons.

Like the 'specialized staff' concepts. Once upon a time, games used to have app staff, plot staff, theme staff, player relations staff, etc. I don't remember what the arguments were against it, but I remember it was widespread, and then it suddenly wasn't. Like, seemingly overnight that setup was abandoned in favor of more generalists.

The rest of this has various high and low points.

First, the 'community' isn't actually a community, it's several, with (obviously) conflicting standards and beliefs across multiple genres, so treating it as a one-and-done seems like a bad idea. We can't even agree on basic things on MSB, which is the closest that currently exists to this. The terminology is kind of weird, and this seems like it has a LOT of levels and moving parts, which just means that it's easier to completely break and harder for people to grok upon starting.

Second, even within like-minded groups, you have in-groups and out-groups, and the in-groups can very easily make life hell for just about anyone, as has been witnessed across multiple games and genres, so 'community reputation' really only goes about as far as 'what the loudest and most vocal people say about you', or how many of your friends you can get to have your back no matter how you are behaving. 'Community reputation' is another word for 'popularity', and that never ends well.

I like some of the concepts. But I think that this approach, specifically related to the parts mentioned above, isn't necessary a great idea.

faraday

@Selerik Yeah, there are many reasons why AresCentral accounts are a) optional and b) not tied to the logins for individual games. Those are both cultural and related to security and trust. I don't think centralized accounts are feasible in MUs today.

Selerik

@faraday They very well might not be. All of this was just a theoretical design, even if it were built exactly as I envisioned it there is the real possibility it would have to be modified to satisfy the community. I try to aim for the why (help the community) and remember the how (centralized login) sometimes misses.

sibermaus

Like the 'specialized staff' concepts. Once upon a time, games used to have app staff, plot staff, theme staff, player relations staff, etc. I don't remember what the arguments were against it, but I remember it was widespread, and then it suddenly wasn't. Like, seemingly overnight that setup was abandoned in favor of more generalists.

There used to be a lot more people who were a) willing to staff, b) capable of doing it (proper mindset, personality, etc.) and c) had time to do it. Now there are less players overall, we're all getting older and having kids, working lots of hours at RL jobs. So those still willing, able, and have the time do a lot more for the game they work on.

Runescryer

Very interesting idea. I'm not a coder, but I had a similar structuring idea a while back in thinking of a Comic Book Multiverse concept. Most of the time, the Universes would remain separate with their own list of characters, so you could have multiple versions and interpretations of, say, Superman, Captain America, Thor, Batman, etc., across the Network. Each Universe would also have it's own staff to run things and enforce theme/concept. So, you could have Universes like: mixed Marvel/DC, pure Marvel, pure DC, Marvel Cinematic Universe, DC Movie-verse, X-Men movies, Arrow-verse, Young Justice, Avengers: Earth's Mightiest Heroes, Earth-2 DC, Ultimate Marvel, and so on. Every so often, there would be cross-over events.

Selerik

@Runescryer Interesting way of approaching this. A lot of the inspiration for my structure comes from how some distributed systems are done for larges enterprises. A core repository for assets, then purpose driven areas where those assets are applied.I admit I don't know what inspired the design originally, I'd be tickled if we're all just cribbing design notes that comic book companies made in the 50s to figure out which universe Bizaro was from.