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.