@Thenomain said:

I'm no longer harshing on "just learn Python and Git, duh"

I never did suggest that anyone should "just learn python and git, duh".

@Thenomain said:

Which is like saying, "Learning to swim is already non-trivial, so you might as well compete professionally."

Yeah, Charles, it's mainly you who I'm accusing of talking over the heads of your audience.

I'm mostly trying to say that if someone has a goal and the cost of learning something non-trivial is worth the benefit of achieving the goal, then they'll spend the cost. The cost of learning mushcode is similar to the cost of learning git and python, at least to the extent required to implement a multidescer or tarot deck. I'm not attempting to compare two things which are vastly different than each other, in terms of time requirements.

As a software engineer, I've played games with mushcode and tried to write things in it. I usually gave up because of the learning curve. I basically stopped just beyond some string formatting commands when trying to write my own code from scratch. I've also used a few user coded things, like multidescers and things that let you show people who '+finger' you in a list, etc. I've also looked at the code and tried to understand it and it seemed impenetrable. Though, importantly, I didn't have to understand it to be able to use it effectively.

Multidescers, tarot decks and anything requiring control flow are complex enough to require a non-trivial learning curve. Anyone willing to climb that hill probably has enough free time and interest to learn git and python, if that was the expectation rather than the expectation being learn mushcode.

Unfortunately, the person can't test their code in the game, but rather, has to set up a game instance of their own. This is a significant burden and I'm not sure how to resolve it in a non-trivial way.

A social side effect of mushcode and the ways it can be shared with others is interesting to consider. It's basically an informal version of open source, in that people write things and occasionally share them with friends and they proliferate. They get feedback from friends and change things and perhaps their friends do the same. Whether their friends use the new version with the changes is up to whether they notice the change or not and whether they care at all.

Let's assume that there is an Evennia based game and someone named Alex joins and is interested in building a multidescer for the game. The developers haven't done it yet, but they are open to 'players' contributing to the project on github. We'll pretend that Alex is motivated enough to overcome the hurdle of setting up a test instance of the game to allow them to write a multidescer. A reasonable way of implementing one that's similar to the way it seems to commonly be done in mushcode would be as a object that a character carries around, with a minor change to characters to allow asking another object for a description. Note, this would allow for multiple different multidescers that follow this interface, just by specifying a different object from which to get the desc.

Evennia has typeclasses which are the functionality for objects when created. The multidescer is then, a typeclass, which is specified when creating an object that any player can create, given the right perms, like: @create my descer : examples.multidescer.MultiDescer. In this case, examples.multidescer.MultiDescer is the typeclass. Typeclasses can have associated commands, so there can be commands for creating and removing items and changing their descriptions, using whatever syntax is desired.

At this point, Alex would create a pull request to the developers, who would accept it after a code review. Alex could then share it with friends, who could use it by creating an object with that typeclass and then get feedback about it. The primary difference at this point would be that when changes are made to the descer, via updating the typeclass, everyone using it benefits, because the code only exists in a single place.

From the perspective of the server owner, this workflow results in less opportunity for rogue code slowing things down or a proliferation of objects which all have distinct instances of mostly the same code. These benefits come at the cost of slower iteration on different designs and a higher bar for a player who wants to customize something for themselves or a few friends.

Experience suggests that whenever game developers allow players to mod their game, players always rise to the challenge. I would expect any game based on Evennia would not be significantly different.

@Thenomain

I'm mostly just suggesting that this thread seems to lack people describing how to do concrete things that other people want to do. I.e. It doesn't seem to be as productive as it could be.

If you have an example of something you want to do, perhaps I (or someone else) could explain how it could be done?

I find it interesting that this thread lacks people describing their experience with using Evennia to do exactly the things people are suggesting it can't do.

For example, I spent a few hours setting up an Evennia server (most of the time was reading lots of excellent docs, thanks @Griatch). I then had a friend connect and I gave them Builder permissions. She then proceeded to build rooms with exits using the default builder commands that look a lot like MUX style commands. And all of this without either of us having to write any python code at all.

If what you want is to be able to have a game where people can build and describe rooms and objects, then Evennia out of the box is sufficient. The only thing that requires python is customizing objects with 'logic' that isn't already defined out of the box.