[Feature Request] Evennia 2.0 Design?

[volundmush]

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

I've been working with Evennia for a great deal of time by now. Tried to tear it apart and rebuild it several times. Have a ton of ideas for it. So you can say that it's related to an overarching theme of problems, more than any specific problem. This might well just be me having no idea what I'm doing... but I'm gonna voice my thoughts anyways and hope that there's at least something useful in it all.

SEVERAL problems of note in the overall design:

1. Evennia's stated goal is to be minimalistic and unopinionated; an easy to approach, barebones Server engine for making any sort of MU*-styled game. MUD, MUSH, whatever. The current effort is quite something. It's very impressive. But I think it's also the wrong approach. See, the inclusion of ObjectDB and DefaultObject as the baked-in default assumption of how persistence, puppeting, and the game map architecture worked is limiting. It forces you to work within an existing framework. As open and flexible as that may be with Evennia, it still forces assumptions upon you, such as 'an Object is either nowhere or inside at most another Object' or 'a mobile or item is always persistent unless you explicitly delete it, rather than non-persistent unless you explicitly save it'.

2. There is no sort of framework for making contribs and people's specific Evennia projects work together/co-exist. Arx and Ainnevve are incompatible for instance. Many Contribs are incompatible with each other. This doesn't necessarily have to be the case. Several of Evennia's contemporaries - AresMUSH and Ranvier chief among them - have a Plugin framework baked in. It may sound contradictory to list both this and Incorrect value of ansi['return'] in ansi.py #1 above, but I think it's possible to make them work together.

Describe the solution you'd like

There really isn't a one-size-fits-all solution to any problem. However, here are some GUIDELINES towards what I think is a better path for Evennia.

First, I would remove AccountDB and ObjectDB and from the default Evennia package. Evennia itself should not include them as a library. Instead, Evennia should focus entirely on the Sessions, and provide an API for Accounts and PuppetedThings to talk to Accounts. The best way to go about this would be, for Accounts, providing an Abstract Account Model that is actually defined inside of a game_template. As for PuppetedThings, it should be entirely up to a developer how that works and how it persists across a @reload, if at all.

In defining neither of these things, Evennia actually achieves what none of its rivals have: being COMPLETELY unopinionated. You would have just a telnet library, an open canvas of a database (apart from a few bare essentials for Accounts), and a crazy amount of useful building blocks. I think TypeclassBase/TypedObject SHOULD be a thing though: the ability to have a Django Model's data be loaded into any sort of logic is wonderful and something that only Python can do with true elegance. Evennia is correct to leverage this. But again if it were me, I would strip it down so that the bare minimum to achieve swappable-Classes exists on its own.

But if you do this, how do you then demonstrate Evennia's usefulness to anyone? Ah, here comes part two of the design changes.

A plugin framework that takes full advantage of the loveliness of settings.py. As I have demonstrated, it is possible to 'break out' of Django's assumed verticality of inherited settings.py configuration. This makes a plugin framework possible. Plugins can define their Auth User Model and other such details. Plugins can define their own Models for game data. Plugins can define whole new kinds of Typeclasses if you wish. And thus, Evennia would provide what it CURRENTLY does - the AccountDB and ObjectDB, Attributes, Tags, etc - as an optional library/package/plugin.

Naturally, there will be plugins that are incompatible with each other. That's unavoidable. If two plugins both want to define an Account model, then... a developer's going to have to pick which gets used. However, I believe that several 'plugin families' could emerge around this central core. There could be one family that specializes in a MUSH style approach inspired by Penn and Rhost. There might be another that's heavily inspired by Diku or SMAUG... all of them going their own directions, but with Evennia as their core.

If Evennia was THAT, then its mission would be accomplished.

[Griatch]

Thanks for the write-up. :) We'll see in the future if this is anything we'll pursue or not.

[tsal]

I agree on the surface with the callout on AccountDB and ObjectDB; I think a good goal would be to decouple those and treat them as interfaces (wrapped or otherwise) that Evennia CAN use but not MUST use. I also think this might be a good post-1.0 goal if it can be done without breaking 1.x.

I'm still thinking about the settings.py changes; I can see advantages there, and I think getting out of the business of using Django's settings for anything other than the website is a good thing. Plugins are definitely a really nice approach to keeping things modular, but making that usable and valuable to the application will take a lot of time - but I also agree that it would be within the scope of Evennia's goals.