[Feature Request] Create more consistent, accessible and configurable stat reporting #3535
Labels
feature-request
A suggestion for new functionality.
needs-triage
Yet to be looked at and verified as an a real issue/feature that could be worked on
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 asyourdomain/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:
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.)
The text was updated successfully, but these errors were encountered: