search

evennia / evennia

Python MUD/MUX/MUSH/MU* development system
http://www.evennia.com
BSD 3-Clause "New" or "Revised" License
1.75k stars 685 forks source link

[Feature Request] Create more consistent, accessible and configurable stat reporting #3535

Open InspectorCaracal opened 1 month ago

InspectorCaracal commented 1 month ago

Strap in, this one's going to be a long one.

Is your feature request related to a problem? Please describe.

At the moment, Evennia supports two very similar, yet completely disconnected mechanisms for game-stat reporting.

MSSP

MSSP is defined here. It's a fairly standardized MUD-centric telnet option for making various information about your game available - genre, uptime, codebase, etc. MSSP allows other services to request the current status and info of your game... as long as those services are using telnet.

Evennia comes with a default MSSP table built into its MSSP implementation, but also allows for customizing and augmenting the information being sent via a module-level dictionary.

MSSP is also antiquated and solely used by a shrinking number of MUD-listing sites.

Evennia Games Index

The Evennia Games Index is an official game-listing site that uses JSON data from subscribing games to create informational listings. It's also integrated directly into core evennia, but rather than allowing other services to make requests to your game, it runs as a polling service within your game and actively sends updates to the game listing site.

Evennia comes with a built-in tool to generate a new file for this game index, which generates a file that contains, again, a module-level dictionary.

Also, while the EGI is very nice and I like having it there, it's also pretty much unmaintained.

Why this status quo kind of sucks

These two modules and their module-level dictionaries are completely independent of each other. Theoretically one could set up one's own game to reference the same module-level dictionary for both services, but as they currently have entirely separate methods of generating certain information and validating the provided information, it could easily just mess both of them up. So we're left with maintaining two separate sources of information about our game if we want to use them both.

Furthermore, this current two-part implementation of Obtaining Game Info is completely lacking in anything to support a more modern-web friendly method of requesting that information. You use MSSP over telnet, or you scrape the EGI, or you go to the game devs and say "hey can I have your game info please thanks". There's nothing that will provide even a basic JSON manifest.

Since the current game-info solutions are so tightly tied to their respective use-cases, adding in, say, a new toggleable-but-provided-by-default view under yourdomain/info, or putting it into the REST API as yourdomain/api/info, or any other info-request solution that's compatible with the modern web, would thus require creating and maintaining info for a third, completely separate system. This means that even that third option - which more realistically might be "hey devs, can you install this code into your game so I can get status reports from it?" - is (aside from lbr sounding very sus) going to be annoying and require more maintenance from the devs. Nobody wants that.

Describe the solution you'd like

The ideal solution requires three things:

  1. Refactor the current MSSP and EGI code to reference a single shared source of truth, the location of which is defined in a single setting.
    • The EGI should still have its own ENABLE toggle setting.
    • MSSP could and likely should have an ENABLE toggle setting as well.
  2. Ensure that whatever validation is necessary for the MSSP and EGI rendering methods is implemented individually in a way that will simply ignore invalid fields. (Based on my cursory review, this should largely work as-is.)
  3. Add a new view (with its own ENABLE toggle setting) or API endpoint (which would be included with the REST API toggle setting) which will provide the same information from the same source as a standard JSON response.

Describe alternatives you've considered

The only alternative solution is to create a third entirely separate system for requesting game info, which would thus need to be separately maintained as well and exacerbate the existing problem. (Or, you know, DNI the idea.)

InspectorCaracal commented 3 days ago

I've had some thoughts about how to implement this, but I've been unwilling to tackle the work required to implement it in a non-breaking change. However. Since my Object search rework that I'm working on will need to be a breaking change, I'm considering pulling together a PR implementing this also as a breaking change that could potentially be merged in the same major version release as the (imo more important) search update.

So if anyone has any thoughts or input regarding this feature request, please leave a comment so I can take it into consideration!

owllex commented 3 days ago

I think this clearly captures the problems with the existing protocols, and in the spirit of DRY, it seems like a good thing overall to merge them in order to reduce repetitive definitions. I know some folks have strong opinions on publishing this data outward, so being able to enable or disable MSSP and EGI reporting seems like a good thing.

For the second part, is your intention to create a new standard for game data reporting, or is it just to ship existing MSSP/EGI data via a new endpoint? I like the idea of an enable-able API endpoint, although it obviously requires external listing sites to already know how to use this in order to scrape game data, so it seems like the usual Yet Another Standard thing. I'm not opposed on this point though, but I wonder if it would get much use without outreach efforts to other sites. Maybe EGI could be changed to use this mechanism?

InspectorCaracal commented 3 days ago

My goal is to work like existing JSON site info "standards", which are, for the most part, "you have a json-type file that's a json object with keys". No requirements or specifications on WHAT keys are present, just a listing or template of commonly recognized keys. Since it's a JSON object accessed via normal HTTP, it doesn't need a new specification or protocol: it just needs to exist.

Although I guess if you consider "providing game information in a format and protocol that is universally supported across the internet" to be a new standard for MU* games, I guess I would be? xD