Evennia - a Python-Based Mu* Server

Thenomain

So this conversation deserves to be taken out of the Shadowrun! thread. Talking about Evennia started here :: http://musoapbox.net/topic/487/shadowrun/35

So I continue here.

@Thenomain said:

@Groth said:

Honestly I've always viewed softcode as a bug rather then a feature. Why would you ever want to insert code line by line through a chat client?

Those who publish, win.

If you're creating a new environment from scratch, why not <etc. etc. etc.>

That's something you should ask the Evennia guys. They have an IRC channel and I'm sure they'd appreciate the input. That's the impression I have gotten so far.

Me, I'm not here to imagine the perfect Mu* replacement. I just think that people who don't have access to the server code still need creation tools.

I realized after I posted this that I didn't pluck out something said by one of the Evennia developers:

As for softcode, it's certainly correct that Evennia does not support softcode out of the box. We choose to differentiate between using softcode for making the core of your game and using softcode for in-game building of cool objects etc. Our philosophy (right or wrong) is that the main game development is best done using Python, in a real text editor rather than inside a line-by-line mu* client. Today development tends to be done by smaller dev teams. Along with the advent of modern version control tools, this diminishes some of the old advantages of softcode, like not needing to give your co-coders access to your server.

For advanced building, Evennia usually recommends for your game to offer a suite of advanced builder commands for in-game users. There are no limits here though - you could expand this into a mini-language as befits your needs. We have a few MUSH/MUX developers developing using Evennia. So far they have all seemed happy to abandon the concept of softcode completely (or maybe this is a selection-effect since they are the kind of people who chose to use Evennia already?). What will rather come of their work is a group-building command suite. This will be made available soon(ish) as an Evennia contrib.

Now I sincerely doubt Griatch reads Soapbox, but it was probative to the whole Softcode thing.

Also, I'm pretty sure I agree with this approach. I certainly don't disagree with it. I use this a bit also in evidence that the Evennia group is reasonable about trying to be more than just a MUDlike. Maybe some day things will be EVlikes.

Ide

Evennia is open to whatever you want to do with it (disclosure, I've been developing an Evennia game and hang out in the IRC a lot). Given that some experienced softcoders write softcode offline and formatted anyway, the difference between mu* softcode and Evennia Python is a little fuzzy.

Bobotron

Volund was on MUSH earlier today talking about converting, straight over, a Penn DB into Python. He didn't seem to be having immediate luck, but there you go.

Thenomain

@Ide said:

Given that some experienced softcoders write softcode offline and formatted anyway, the difference between mu* softcode and Evennia Python is a little fuzzy.

It's no guarantee that the content creators of a game have access to the server for uploading their creations. To try and make my point, I focus on the "builder" level of coding: setting up rooms, locks, descriptions, more locks, day/night ambiance effects, setting up places, views, and so forth.

A lot of the time builders are interacting with softcode and don't realize it; it's for this reason that I believe that Griatch is making the distinction between "main game development" (mostly what I do these days) and "in-game building" (and toy-making).

But let's face it, a lot of the cool Mush tricks that we've done over the years are because we didn't need server-level access to try new things. I built a repeat-until loop using nothing more than @trigger and @if and if you don't think that's fun then you're probably sane, but I didn't need to beg for server space or access to make increasingly complex and fun toys. If I did, then I probably wouldn't've bothered.

Derp

I will admit to having some hesitation when I see this come into play.

First of all, I'm an aspiring coder. I'm very slowly learning the ins and outs of the code. I've made a few toys here and there. Nothing major -- I think my biggest project is Eldritch's idle tracker, and that doesn't even have automation. But it's a start. And it's a start that doesn't require me to have a lot of things in the way of powers and permissions and such. I even have a few 'handy little tools' that I use by way of softcode that make my job easier, like a thing that just lets me take a job number and a few bits of information and plug it in to handle wiki account requests. Those are the sorts of toys that I like to make, and one of the reasons that I like mux code.

Mux has all of the help files built into the thing, and doesn't require me to go outside of that in order to figure out what I'm doing. This, on the other hand, requires knowledge of python, programming, and other things that are currently beyond my ken, much less my permission level.

There are few enough people who do MUX code in any serious capacity as it is. With Mux, though, it's open for anyone who wants to learn. The tools are all right there for you, and you can play around with little things in the game itself to get a feel for it. With this system, I don't think that will be possible. Given the dearth of coders that we currently have, taking away the ability for an aspiring amateur to do anything reasonably sound with it by way of practice and play seems... I dunno. I don't think it'll have a good effect on things, in the long run.

So I'm hesitant to climb on board with this, no matter how shiny it is. Half of the reasons I enjoy these games so much is because they allow me to learn something like that on my own time, in a self-contained environment where I can see real effects, real examples, etc. Evennia might have all the cool things ever, but it's lacking that big draw for me in the form of not having any access to tools by which I can create my own things, unless a coder helpfully installs such things, which seems defeatist of the point of moving away from softcode.

Groth

So looking through the Evennia documentation it seems to support most things that builders would expect out of softcode. The main thing it does not support is the ability to define commands however in my experience builders do not usually need or want to define commands.

The bigger issue I see is that the command library looks rather sparse. For instance their example smile command looks like this

from evennia import Command

class CmdSmile(Command):
    """
    A smile command

    Usage: 
      smile [at] [<someone>]
      grin [at] [<someone>] 

    Smiles to someone in your vicinity or to the room
    in general.

    (This initial string (the __doc__ string)
    is also used to auto-generate the help 
    for this command)
    """ 

    key = "smile"
    aliases = ["smile at", "grin", "grin at"] 
    locks = "cmd:all()"
    help_category = "General"

    def parse(self):
        "Very trivial parser" 
        self.target = self.args.strip() 

    def func(self):
        "This actually does things"
        caller = self.caller
        if not self.target or self.target == "here":
            string = "%s smiles." % caller.name
            caller.location.msg_contents(string, exclude=caller)
            caller.msg("You smile.")
        else:
            target = caller.search(self.target)
            if not target: 
                # caller.search handles error messages
                return
            string = "%s smiles to you." % caller.name
            target.msg(string)
            string = "You smile to %s." % target.name
            caller.msg(string)
            string = "%s smiles to %s." % (caller.name, target.name)           
            caller.location.msg_contents(string, exclude=[caller,target])

That is not a reasonable way for such a simple function to be written. One of the few strengths of MUSHcode is that it has very powerful and easy to use parsers built in and all the relevant variables like the caller, target, arguments etc are already pre-stored into default substitutions variables.

WTFE

@Derp said:

Mux has all of the help files built into the thing, and doesn't require me to go outside of that in order to figure out what I'm doing. This, on the other hand, requires knowledge of python, programming, and other things that are currently beyond my ken, much less my permission level.

So ... run a local copy and do what you like for learning purposes. In terms of documentation, there's a myriad more resources available that are far superior to anything that the MUSHing world offers in terms of learning.

And you'll be learning to code in a far easier language that has uses outside of pretendy fun-time games on top of that!

There are few enough people who do MUX code in any serious capacity as it is.

This is because MUSHcode is a fucking terrible language and anybody who a) actually knows how to code and b) is sane avoids it like plague.

With this system, I don't think that will be possible. Given the dearth of coders that we currently have, taking away the ability for an aspiring amateur to do anything reasonably sound with it by way of practice and play seems... I dunno. I don't think it'll have a good effect on things, in the long run.

To the contrary, however, I think it will be a far better thing in the long run because there are about ten thousand already existing Python coders for every MUSHcode coder that can do anything seriously. (Yes, I think four orders of magnitude difference in numbers is about right.)

Griatch

@Groth said:

So looking through the Evennia documentation it seems to support most things that builders would expect out of softcode. The main thing it does not support is the ability to define commands however in my experience builders do not usually need or want to define commands.

The bigger issue I see is that the command library looks rather sparse. For instance their example smile command looks like this
from evennia import Command

class CmdSmile(Command):
    """
    A smile command

    Usage: 
      smile [at] [<someone>]
      grin [at] [<someone>] 

    Smiles to someone in your vicinity or to the room
    in general.

    (This initial string (the __doc__ string)
    is also used to auto-generate the help 
    for this command)
    """ 

    key = "smile"
    aliases = ["smile at", "grin", "grin at"] 
    locks = "cmd:all()"
    help_category = "General"

    def parse(self):
        "Very trivial parser" 
        self.target = self.args.strip() 

    def func(self):
        "This actually does things"
        caller = self.caller
        if not self.target or self.target == "here":
            string = "%s smiles." % caller.name
            caller.location.msg_contents(string, exclude=caller)
            caller.msg("You smile.")
        else:
            target = caller.search(self.target)
            if not target: 
                # caller.search handles error messages
                return
            string = "%s smiles to you." % caller.name
            target.msg(string)
            string = "You smile to %s." % target.name
            caller.msg(string)
            string = "%s smiles to %s." % (caller.name, target.name)           
            caller.location.msg_contents(string, exclude=[caller,target])
That is not a reasonable way for such a simple function to be written. One of the few strengths of MUSHcode is that it has very powerful and easy to use parsers built in and all the relevant variables like the caller, target, arguments etc are already pre-stored into default substitutions variables.

@Groth

Ah, I guess I should take my first post on musoapbox (hello everybody) to comment on this technical aspect of Evennia's design. For full disclosure - I'm the Evennia lead developer.

Evennia actually does make a minimum of "relevant" variables available in its base Command class. For example you will find self.args (the arguments to this command), self.caller (who called this command) and so on already available on the Command instance. There are some 10 dynamic variables available to the Command at runtime related to the call of it, the object it is assigned to and so on.

The Command class is however (by default) not knowing anything about what syntax you want your commands to support - all it knows at this point is that it has figured out what command-name is being called (the first part of your input, which can have any length, including spaces, how we determine this uniquely is a technical issue I'll leave for now) - the rest of the input string is just dropped in self.args. It's now up to you to parse that.

Now, it may sound like you need to do a lot of parsing all the time (and the smile example is just that - an example where a simple parser was introduced). But the thinking behind the Command system is that Commands are Python classes, and those can be inherited. This means that you implement the parse() method once, storing all the "relevant variables" the way you want. You could also make a little helper method to easily template your return messages to your particular preference (Python excels at string manipulation after all). All other commands that share a similar syntax can now inherit from your custom "MUSHCommand" class and not have to worry about parsing themselves - you'll have all the convenient variables available directly in func(), where you want them to do whatever your command should do.

This is in fact how we implement our "MUX-like" default commands throughout Evennia: they all inherit from MuxCommand, which parses the incoming argument into understanding stuff like /switches, the use of = for assignment and so on. We have a second base class for some admin commands which (some of which were originally borrowed from a MUX flavor) really go all out in syntax complexity ...

Is Evennia's Python code more verbose than softcode, covering more lines for the same functionality? I've not done a comparison - my softcode skills are severely lacking I must admit - but you are probably correct in that.

As for the default command library, there are currently about 90 commands in Evennia's default set I think. These are by no means intended to be comprehensive though; most are admin-level stuff (boring stuff all games need). We expect most commands will be modified to fit each game anyway. We could certainly offer more Commands to build from in our contrib/ folder though, this is a slowly growing resource.
.
Griatch

Griatch

@Bobotron said:

Volund was on MUSH earlier today talking about converting, straight over, a Penn DB into Python. He didn't seem to be having immediate luck, but there you go.

I believe he succeeded with that now.
.
Griatch

Griatch

@Thenomain said:

@Ide said:

Given that some experienced softcoders write softcode offline and formatted anyway, the difference between mu* softcode and Evennia Python is a little fuzzy.

It's no guarantee that the content creators of a game have access to the server for uploading their creations. To try and make my point, I focus on the "builder" level of coding: setting up rooms, locks, descriptions, more locks, day/night ambiance effects, setting up places, views, and so forth.

A lot of the time builders are interacting with softcode and don't realize it; it's for this reason that I believe that Griatch is making the distinction between "main game development" (mostly what I do these days) and "in-game building" (and toy-making).

But let's face it, a lot of the cool Mush tricks that we've done over the years are because we didn't need server-level access to try new things. I built a repeat-until loop using nothing more than @trigger and @if and if you don't think that's fun then you're probably sane, but I didn't need to beg for server space or access to make increasingly complex and fun toys. If I did, then I probably wouldn't've bothered.

I'm answering these posts in a bit of a wrong order, sorry about that.

In short - yes you are correct here: If you are used to games where the normal player can do cool programming in softcode without any input from staff, then Evennia will not appease your needs, at least not out of the box: we are currently not offering safe program-flow structures on the in-game command line (Also, before anyone asks, alas you can't safely use Python itself to fill this role - this is the cost we pay for Python's awesome introspection and flexibility - it is not designed to be programmed by untrusted programmers ... which, from the perspective of the server-owner, every player is. Hence our in-game @py command can and should only be made available to superusers.).

Our suggested solution is for the coder to provide the builder with sophisticated build commands - and with the full access to the entire Python library in the wild you can make those very powerful if you want. But that said - if people want to they could of course also build their own softcode-like mini-language in Python and offer that; our Command system could support it without any modification. So far no MUSH developer working with Evennia has expressed any such desire but maybe that's coming.

As a side note, I should point out that "server level access" is not what it once was. Modern version control systems usually don't require code contributors to have any access to the running server whatsoever. Contributors can just push their code to the repository (which may sit on a free, private repo on say, bitbucket) and make a push request. The server owner can review this and pull down and merge (or not) as they see fit. There is no security issues here (as long as you check the code) and no reason to limit who may offer input. This workflow is definitely not as "direct" as in-game softcode and more relevant to bigger code development and staff collaborators than to a specific experimenting player though.
.
Griatch

Thenomain

@Griatch said:

As a side note, I should point out that "server level access" is not what it once was.

This is an important note, yes, but I was summarizing for both expediency and to keep from making myself look like an idiot. I wouldn't have the time to review code that, e.g., makes an object follow me from room to room. I have come to trust the server itself to be trustworthy in making this something that can be performed without breaking security. Theno, install my Follow code! Theno, install these three different multidescers! Theno, one of the multidescers is not working please debug it! Theno, that bug has been in for months but people still use it even halfway broken can you take a moment to fix it for us please?

Yeah, this happens. The most fun was when someone fixed some of our code, it ended up more broken, and she refused to fix the bugs leaving me responsible for code that I subcontracted out so that I didn't have to worry about it in the first place. I can be pretty draconian about what I allow in the Master Room (game-wide code implementations) anymore.

Mind, I did promise @Chime that I would make the MUSHlike interfaces if she did what you guys are doing, so I am willing to make it happen. The question is do I have the time and drive. You know how that goes.

Griatch

@Thenomain said:

@Griatch said:

As a side note, I should point out that "server level access" is not what it once was.

This is an important note, yes, but I was summarizing for both expediency and to keep from making myself look like an idiot. I wouldn't have the time to review code that, e.g., makes an object follow me from room to room. I have come to trust the server itself to be trustworthy in making this something that can be performed without breaking security. Theno, install my Follow code! Theno, install these three different multidescers! Theno, one of the multidescers is not working please debug it! Theno, that bug has been in for months but people still use it even halfway broken can you take a moment to fix it for us please?

Yeah, this happens. The most fun was when someone fixed some of our code, it ended up more broken, and she refused to fix the bugs leaving me responsible for code that I subcontracted out so that I didn't have to worry about it in the first place. I can be pretty draconian about what I allow in the Master Room (game-wide code implementations) anymore.

@Thenomain

To exemplify this in the standard Evennia paradigm, things like "code to make people follow me" is fundamental enough to be developed during the actual construction of your game, something part of your design specification or added as a later, formal patch.

What you are referring to as "things you don't have time for" really describes the normal debug cycle of almost all other computer programs in the world. It's cool that softcode lets you-the-admin off the hook in the sense that you don't need to worry about contributed softcode taking over your computer. There is no denying it works. I'm not so sure this lack of central oversight is the best practice for a long-running multiplayer game you want to consistently and stably maintain though. This has nothing to do with softcode per se: it's just that code that is "safe" from the server perspective doesn't necessarily mean code that is actually working/efficient/readable/upgradable. Again, remember that I'm referring to core system code here, not creative builder stuff.

Under a version control system, even if a buggy update slipped through the net, you could then easily look back in the file history to see where a particular line was changed and by who - and then reverse that code back to the (in your example slightly better working) previous version with equal ease.

Btw, to show you are truly draconian you demand unit tests ...

Mind, I did promise @Chime that I would make the MUSHlike interfaces if she did what you guys are doing, so I am willing to make it happen. The question is do I have the time and drive. You know how that goes.

I'd be interested in hearing what MUSHlike interfaces you promised and what you consider such interfaces to be! What do you mean by "if she did what you guys are doing" though - could you clarify what you refer to?
.
Griatch

golgoth

I know @Reason touched on the following, but I wanted to remind people in this thread (Reason mentioned this in the ShadowRun thread). Here are several places where you can learn Python programming for free:

@Reason mentioned University of Michigan offering free Course at www.coursera.org/learn/python.

There is Cybrary (cybrary.it)that offers Python for Security Professionals, which is actually set up to take you from knowing nothing of Python to... well... knowing enough about Python to automate some of your security tasks.

Finally, there is Codeacademy (www.codeacademy.com) that aims to be a straight hands on learning experience in a similar (to me) vein as the book Learn Python the Hard Way.

Additionally, local libraries and online resources such as Safari books have a ton of material dedicated to teaching you Python for free.

Thenomain

@Griatch

That is an awesome developer view, and I appreciate it, but to me, a Mu* is a toy, a toy for making tools, a toy for making toys, a toy for RP, a toy for pew pew combat mechanics, but foremost a toy. Or a structure for making toys.

I started by scripting internally, and I have helped get people excited about coding because of it, so to me, it's important.

What kind of Mushlike tools was I going to make? Well it depended on the shape of the server. Which is to say, we never got that far. You know, whatever. Probably nothing structured.

Griatch

@Thenomain said:

That is an awesome developer view, and I appreciate it, but to me, a Mu* is a toy, a toy for making tools, a toy for making toys, a toy for RP, a toy for pew pew combat mechanics, but foremost a toy. Or a structure for making toys.

Fair enough.
.
Griatch

Reason

@Derp I would have to respectfully disagree with your characteristic of MU* code being open to anyone who wants to learn. MU* code is open to anyone who wants to search archaic remnants of an age long since past, and invoke an animal spirit code guide with a mix of peyote and pleasant page-chats.

Which isn't to diminish the importance or joy or learning MU* code anymore than the importance or joy of learning Haskell (or really any functional programming paradigm, for that matter) -- just that hanging your hold-ups on the accessibility of MU* code is odd when it is 1) Not actually accessible afterall 2) Less accessible than a number of modern languages (by orders of magnitude), including the direct contrast of Evennia's Python.

My own concerns are much closer to the challenges of changing creatures of habit.

We of the MU* like our MU*ness to be of a certain character.

Evennia is a foreigner in that regard, who exhibits the capacity to over time learn our languages and holy customs, but has not yet made a pilgrimage to the shrine of... whatever soft-code gods we hold dearest.

That said, it is exciting -- I feel that it is a step in the right direction, for both the sustainability of the hobby with respect to code support (I will probably never write another line of MU* soft-code so long as I live. Maybe. Okay, probably maybe.), as well with respect to the accessibility of new players (Native web client vs. reskinned 1970s Telnet).

SparklesTheClown

MU*s are like "Fuck sliced bread, I want to cut my bread. God, what is with people and their goddamned modern plumbing and heating? Plebs. Sorry, I only listen to the radio, television shows are for lazy assholes and they're ruining entertainment. And god, those damned talking picture movies? No thanks."

We need things like Evennia to kick this hobby in the ass and actually try to evolve with the rest of the internet. I'm looking forward to it. Though I still want to make something even simpler that doesn't even require coding to make a MU (Future code goals), making something that uses Python is -really- good, because there some extremely simplified resources to learn it that doesn't involve combing through piles of documentation.

Derp

@Reason said:

@Derp I would have to respectfully disagree with your characteristic of MU* code being open to anyone who wants to learn. MU* code is open to anyone who wants to search archaic remnants of an age long since past, and invoke an animal spirit code guide with a mix of peyote and pleasant page-chats.

Which... doesn't mean that it isn't open to anyone who wants to learn, that just means that it's something that they'll have to put some actual work into, and maybe seek a mentor. Much like anything else anyone could ever hope to learn. But all of the documentation for it is included in the help files, along with examples and such, and outside of a few concepts which are rather buried, you need not ever really seek an outside mentor. It's all self-contained. But more importantly, it can be used within the game itself without having to worry overly much about server access. Ergo, open to anyone who wants to learn.

Which isn't to diminish the importance or joy or learning MU* code anymore than the importance or joy of learning Haskell (or really any functional programming paradigm, for that matter) -- just that hanging your hold-ups on the accessibility of MU* code is odd when it is 1) Not actually accessible afterall 2) Less accessible than a number of modern languages (by orders of magnitude), including the direct contrast of Evennia's Python.

Except that any MU user can create their own softcode to do specific things they want it to do that might not be important enough to implement game-wide, and they can do so without having to worry about server access, etc. Anything that could super easily break things is largely denied due to permissions. The same cannot be said of Evennia. It might not be something that a great many users ever pursue, but it's something that I find important enough to dissuade me from looking into Evennia.

My own concerns are much closer to the challenges of changing creatures of habit.

We of the MU* like our MU*ness to be of a certain character.

Evennia is a foreigner in that regard, who exhibits the capacity to over time learn our languages and holy customs, but has not yet made a pilgrimage to the shrine of... whatever soft-code gods we hold dearest.

I think we can agree on this.

That said, it is exciting -- I feel that it is a step in the right direction, for both the sustainability of the hobby with respect to code support (I will probably never write another line of MU* soft-code so long as I live. Maybe. Okay, probably maybe.), as well with respect to the accessibility of new players (Native web client vs. reskinned 1970s Telnet).

Potentially. We shall see.

Thenomain

@Derp said:

Except that any MU user can create their own softcode to do specific things they want it to do that might not be important enough to implement game-wide, and they can do so without having to worry about server access, etc. Anything that could super easily break things is largely denied due to permissions. The same cannot be said of Evennia. It might not be something that a great many users ever pursue, but it's something that I find important enough to dissuade me from looking into Evennia.

I was thinking about the question posed to me earlier, concerning what I would've coded for @Chime's theoretical Mush replacement, and I decided that a permissions/roles system would be at the very top of that list.

For Eldritch, I created a very extensive "approval" system code, that checks for the status of: Guest, Staff, Chargen (brand new), Approved, Unapproved (de-approved), Frozen, NPC, and Storyteller. I wished like all getout that I could lock the @name, @alias, and @moniker commands to !Guest, !Frozen, !NPC, !Storyteller.

Then I was thinking that the Builder flag that Mux has isn't terribly useful, because I can't allow or disallow certain important commands that happen to be Wizard-only.

Without even looking, I bet I could set up Roles in Evennia. But until I do, I agree with you, @Derp.

ThatOneDude

I like it... This could open the door for a whole new set of programers.

Was there a link to the code to check out that I missed or does this fall into the realm of:

link text