Evennia - a Python-Based Mu* Server

Volund

I know how to play Game X. I log into similar Game Y and man oh fucking man what the hell is going on here? Never mind!

Not really sure what anyone expects can be done about that.

I'm working on Evennia for several reasons.

The first is that I wanted to learn Python.

Second, I think that while MUSHcode is -capable- of doing some complicated stuff it is hardly OPTIMAL for it compared to modern languages like Python. Case in point, it took me less than a third the time to write a BBS similar to Myrddin's in Python once I knew how to Python at all.

Thirdly, many of the games I support don't care much about player building. Most of them are MUSHes of the same family as Megaman MUSH, where the objective is a roleplay setting where you grab some character and just go RP. The most people do is build some cool room with a desc to roleplay in. Almost nobody uses the available softcode tools for anything, so the loss of softcode for my purposes in the immediate future is not a big deal.

Fourth, the advantage of having a website that will be suited for things like reading or posting on the BBS, admin tools of countless varieties, and a webclient that does not suck will be a hundred more times approachable and easier to gain the attention and approvla of newbies to the hobby.

So what if it's difficult to randomly create an object to represent a dog that barks at people randomly while they enter the room? That can come later.

@Griatch

Also, and I don't know how much this is a factor in MUSH, but at least on the MUD side there are a ton of extension subnegotiation protocols that has been added to the Telnet protocol over the last 20+ years. They tend to be poorly documented (since there is no central standard) and various clients support subsets slightly differently or straight-out wrong. This is not making it easy for a server developer.

MXP, MCCP, Pueblo... GCMP? I don't know anymore, it really is that chaotic.

Griatch

@Tirit said:

@Griatch
Yes. But if you have a for example -- typeclasses/character.py in your development folder on a development box, and you go to pull from a repo that same folder, it won't it because it sees the issue as a version control issue, and wants to know if you need to stash, merge, etc. So they delete the folders, all of them, not realizing that they need to keep server/, because that's not on the repo, because that more game specific. Now they're confused on why the game does start.

For those not familiar with a git or version control set up, this can get confusing. For those who are familiar with it, they just know to delete the specific folders that are on the repo and nothing more. Then do the pull and it will give you the repo version.

Again, nothing wrong with the way Evennia has done it, just been a snag for developers who don't know git.

I think what is confusing me is why your devs have their own copies of the game folder at all. Only you need to run --init. They should never need to run --init of their own, they just clone your pre-initialized game folder so that you can all collaborate on it. There is then never a problem with file collisions.
.
Griatch

Griatch

@Thenomain said:

[10/12/15, 3:17:02 PM] Thenomain: There is no “log in and add things”. It’s all “get the game owner to add things”.
[10/12/15, 3:17:46 PM] Thenomain: Advantage: Make complex changes like “a stat system” super easy.
[10/12/15, 3:17:48 PM] Coin: Right.
[10/12/15, 3:18:04 PM] Thenomain: Disadvantage: Make simple things like “a dog that barks when someone walks into the room” super hard.

Belatedly (somehow I missed this post in the general flow earlier, sorry): Also without softcode you could as a developer relatively easily prepare "a generic object that has slots which users can fill with custom content": Like an object that a user can name ("dog") and which has a property string_to_use_when_char_enters (should probably have a better name ;)) - this string you could as a coder parse for template markers so you can include the name of the character entering and so on. You could allow a list of room names for the object to move between, and how often. It could accept a list of strings to be randomly echoed or be allowed selectors as to who it should interact with in a particular way ... and so on.

Not as flexible as full softcode, surely. But from the perspective of the end user ... you could extend the functionality of a "template" object to allow a player quite a substantial level of creatitivity with such simple means.
.
Griatch

Thenomain

Hey, all I had when I started was @trigger, @listen, @if, and a handful of functions. I think the goal of softcode, in my mind, is not to expand the kind of game it is right now, but to extend the server into the game interface itself.

I could be wrong, tho, because everyone has their own way of describing all this madness.

edit Uphill in the snow, both ways!

Reason

Yeah, after some thought, honestly I think that extending LARGE chunks of "soft-code" into Evennia wouldn't be that daunting. Particularly for the BLDR role.

It wouldn't be too difficult to put some simple flags in place to check permissions, publish some quick help files, and then presto -- MU* BLDR-a-tron 5000.

You'd just need A) Time B) Mountain Dew or Lighter Fluid C) List of MU* BLDR commands.

Tirit may have already taken a crack at it on Deep Shadows.

Bobotron

@Thenomain said:

@ThatGuyThere said:

Also on MUSHes the billboards, mail system, and channels for the most part are soft-coded as well.

Mail is hard-coded these days. Only on Penn (and for their own reason, Haunted Memories) do I know the channel system softcoded. The bboards should be hard-coded. As well as the cron system. As well as the stat system. As well as the dice system. As well as ...

If you see what I mean.

Penn's channel system is part of the core package hardcode, as is mail, just an FYI. Some Penn do softcode channels in addition sometimes.

WTFE

@Reason said:

I appreciate your interest in softcode, mind you. I think that the world would be a better place if more people took a moment to think about functional programming. W.W.H.D., that's my moto.

Pity that MUSHcode is to functional programming what SNOBOL4 is to structured programming.

WTF kind of "functional" language doesn't have functions as first-class types that are easily composed!? Oh, right. MUSHcode. The language invented by someone who took a Lisp class but didn't understand it.

Reason

@WTFE said:

@Reason said:

I appreciate your interest in softcode, mind you. I think that the world would be a better place if more people took a moment to think about functional programming. W.W.H.D., that's my moto.

Pity that MUSHcode is to functional programming what SNOBOL4 is to structured programming.

WTF kind of "functional" language doesn't have functions as first-class types that are easily composed!? Oh, right. MUSHcode. The language invented by someone who took a Lisp class but didn't understand it.

Here you go. Ready for Evennia.

acharles

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.

Thenomain

@acharles said:

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.

Counter-interesting: I find it interesting that the communication to the people who think it can't do it (really: want to make sure it can) has been addressed in one post that talks technology above their head, and a second post that starts "I find it interesting" and implying that these people be the ones to prove the absence of something.

I don't think it's up to the Evennia devs to hand-hold people through new concepts, but I do think we could to better than this. Otherwise, I'm chalking it down to people in Camp A not really understanding people in Camp B, and people in Camp B lacking the training to understand people in Camp A.

Or in other words:

@Thenomain said:

Hobbyists vs. Professionals, FIGHT.

acharles

@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?

Thenomain

@acharles

Sure. Hold on while I go out, re-learn Python, understand Git, and then pour over the Evennia code structure and documents. And I'm one of the people more likely to do these things because I already have a background in coding. Many of the people responding here don't, while many do. It's a grab-bag.

Someone could answer with, "It can already do that. Look here: <link>", and render the complaints moot and turn it back into a discussion. That person is not yet me.

(implication/translation: turning information gathering into concrete project goals is not up to the end-user.)
(another implication/translation: educate these poor people to get them excited in the project, don't blame them for not trying!)

Tyche

@acharles said:

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.

I don't think that's the issue. Online building has been ubiquitous in mudding for twenty years. From TinyMud to MOO to LPMud and even most Dikumud derivatives. I'd be hard pressed to find one running today that didn't support online building. I'm quite sure Evennia is just as capable in that regard.

One issue that might be troublesome is how Mush operates. Unlike MOO, LPMud, Cold, or Dikumuds (with their DGScripts or Mobprogs), which separate the command interface from the language compiler/parser, the Mush command interface IS the Mushcode interpreter. This is analogous to presenting the Evennia user with the Python shell on login. For all practical purposes every player that logs into a Mush is in an "interpreter shell". Whether they do so or not, Mushcode can be embedded into the commands they execute. This unusual design is probably why you see very few attempts at writing a Mush parser.

Griatch

@acharles said:

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.

Yes, I hope people were not confused about this - Evennia offers online building just fine. You don't need something like softcode for stuff like building rooms and describing them, setting configuration options or customizing your output. The "softcode" we refer to (in this context) is for more complex stuff.

@Thenomain said:

Counter-interesting: I find it interesting that the communication to the people who think it can't do it (really: want to make sure it can) has been addressed in one post that talks technology above their head, and a second post that starts "I find it interesting" and implying that these people be the ones to prove the absence of something.

I don't think it's up to the Evennia devs to hand-hold people through new concepts, but I do think we could to better than this.

I presume I'm the one writing posts that "talks technology above their head". I'm sorry if that's the impression but when people are commenting on a particular aspect of Evennia design (such as my first post was replying to the length of Evennia command code), it sort of makes sense that I reply explaining that design from a technical standpoint.

Someone could answer with, "It can already do that. Look here: <link>", and render the complaints moot and turn it back into a discussion. That person is not yet me.

I might be mis-remembering but I have not seen any such complaints beyond "I want softcode on the command line". As I've already said, we don't offer softcode like this out of the box, instead recommending advanced build-commands for building and Python for back-end development. I even suggested (without technical jargon) how player-agency could be implement as "template" object they can customize safely. You could implement softcode in Python. Not sure what else I can say on this to appease you, but I'm open to further suggestions on what information is useful.

Edit: Maybe we can convince @Volund to post some of his MUSH softcode next to his equivalent Evennia code, for those interested.
.
Griatch

Griatch

@Tyche

[MUSH softcode design] is analogous to presenting the Evennia user with the Python shell on login.

Yes, this is a good analogy. Well, expect that the reverse MUSH-equivalence to giving access to the Python shell is to let the MUSH user toy freely with the C hardcode in-game (if such a thing was possible).
.
Griatch

Derp

@Griatch said:

I presume I'm the one writing posts that "talks technology above their head". I'm sorry if that's the impression but when people are commenting on a particular aspect of Evennia design (such as my first post was replying to the length of Evennia command code), it sort of makes sense that I reply explaining that design from a technical standpoint.

It's not just you, man. There seems to be a lot of this going on. See also:

@Reason said:

Yeah. Well, it's tough for me to continue here because you don't have a frame of reference beyond soft-code.

So I can talk about "accessibility" and "utility" and attach shiny buzz words next to the modern programming capabilities that surround Evennia, but that's just really words on a page that you don't understand in a tangible sense.

Because your experience as an aspiring coder is limited to a whitespaceless functional paradigm, typed into a chat client.

So if people seem a bit defensive, it's because ... we are. Some of us are trying to talk about there being actual drawbacks to these things that don't appeal to current members of the community when this is supposed to be a tool for the advancement of that community. One of the shared values of this community is for multiple people to be able to functionally contribute meaningful things to the game on a large scale as well as develop more personalized things for their own use. There is a very high degree of customization that you can do with data manipulation using softcode, even if people don't realize that the multidescers and tarot decks and cell phone objects and vehicles and such are part of that softcode.

The answers given so far seem to be a lot more along the lines of 'ugh, why would you want to do that, that's stupid' and a lot less along the lines of 'oh hey, I see where you're coming from and why it's important to you, and I think I have a solution as to how we can get something that might appeal to you'.

Bring it down to the level of the people the discussion is aimed for. It's far more realistic to go to the mountain than to expect the mountain to come to you.

Because it bears repeating:

@Thenomain said:

Someone could answer with, "It can already do that. Look here: <link>", and render the complaints moot and turn it back into a discussion. That person is not yet me.

(implication/translation: turning information gathering into concrete project goals is not up to the end-user.)
(another implication/translation: educate these poor people to get them excited in the project, don't blame them for not trying!)

Griatch

@Derp said:

multidescer

Now you are talking over my head ;). Could you elaborate on what a multidescer is and how it should work? I could then take a stab at explaining how it would be implemented from the Evennia perspective of things.
.
Griatch

Derp

@Griatch said:

@Derp said:

multidescer

Now you are talking over my head ;). Could you elaborate on what a multidescer is and how it should work? I could then take a stab at explaining how it would be implemented from the Evennia perspective of things.
.
Griatch

Ok, so... let's pretend, for a second, that Evennia comes with only your basic hardcoded mush commands.

Everyone is familiar with @desc, and how it works. You set an attribute on something wherein you can see a description of it using a look command. However, there is only one available desc attribute at any given time -- to change it, you have to delete the old one and put in a new one.

Well, a multidescer allowed you to take various descs and save them in other attributes, changing them up as you see fit, using whatever command syntax makes sense to you. You can even store pieces of descs, which are then compiled into a larger paragraph.

So you might see something like:

+desc Formal Attire

or

+desc Red Hat & Blue Hoodie & Faded Jeans & Work Boots

all of which are stored in their own various places and swapped out with the current desc, which is stored in its own 'save location' attribute.

Another is the ability to create very simple objects that do very simple things, like, give you a random spread of tarot cards and a keyword list of associated meanings.

But really, focusing on the one thing is missing the forest for the trees. The point is that in many branches of MU, players have the capability to create these things for themselves right out of the box and they are portable between any game using the same MU version without having to go through what is almost assuredly the tedious process of having to vet this thing through your primary developer. Things that are NOT, by default, a part of the hardcode, and so are not available to them unless they choose to create it.

Sure, they could vet it through the dev, but each of them has a various preference on which one to use and even how it's used (this is a classic example of how softcoding is used to highly personalize an experience).And a developer might not agree that it's important enough to turn into a globally accessible command. Even if they do, you could end up with eighteen versions of a thing that does something in similar but different ways, which doesn't simplify your process at all -- it just creates command bloat.

This type of end-user personalization is what I'm talking about -- the ability to create things for their own personal use, which does not necessarily have any larger impact on the game world. MUX can do this with its softcode implementation -- how, then, can Evennia do something similar?

Evennia relies on a completely different code implementation, which doesn't use softcode nor does it offer anything similar to it right out of the box.

SparklesTheClown

I'm always surprised when people mention MOOs in the same breath as MUDs. It's true, obviously, I don't deny it, but it's jarring because my primary encounters with MOOs are the ones made to work like MUSHes (No idea why people go through the trouble, instead of just making a MUSH).

But anyway, on the topic of building for the community. The community is already here and have tools that they're more than comfortable with, Evennia is something new that can possibly be used as a tool for new coders from outside of the community who can't possibly see why they'd bother with the current options.

Maybe I'm wrong, but I don't really view the priority of something like Evennia to be purely for maintaining the status quo in every way possible. But even if it was, people have illustrated that this isn't difficult to accomplish. Which is obvious if one has played a MUD. If people want to give options to build, MUDs have been giving players easy options to build for years, so obviously it's not beyond Evennia to be able to do if a particular game sees fit.

I'm not totally sure why we're still on this 0_o. People settled it multiple times by saying, "Yes, we can totally do this".

Griatch

@Derp

I hear you on the softcode's abilities. The boring answer is "Yes, you can totally implement softcode in Evennia without modifying Evennia itself. And no, it's not there out of the box". Bear with me though, I'll try to further explain this stance from the Evennia perspective.

Firstly, let's separate between developers and players. Whereas this distinction is fuzzier in MUSH softcode than in other game styles, I'm willing to bet there are still people who are actually trusted to modify the core of the game experience for everyone and others that are not. For this analogy let those be the developers and the players respectively. In both cases I think we can assume that developers are the ones expected to learn the tools the best, are accountable for keeping coding standards and generally maintaining the game's best practices. Only developers can make "cheating" stuff that affects others than themselves (so if you are offering totally free online coding like lambdaMoo this analogy fails).

Let's start with the multidescer since it's a concise example. From the perspective of the player, you have described this as a command that you use to add one or more descriptions, also with the possibility to swap one's active desc later. The player also expects to be able to modify the call signature of this function and even how its arguments are input.

Now, in Evennia, the functionality of the multidescer is the work of the developer. Coding it in Python is simple: without going into the technical lingo, it's a matter for the developer to just add multiple description storage slots on the character - these are automatically persistent and can be searched, organized and modified very efficiently. The default @desc command would maybe be expanded to look something like this: @desc/store name_of_description = description. It may even accept an optional list of inputs if you wanted that. Internally, this would just be added to the storage and could easily be retrieved later by whatever syntax you want in order to actually update the desc property on the Character.

So how about the players' ability to modify their experience of this functionality? Evennia has a "nickname" system (controlled in-game by @nick by default). This replaces the input dynamically. So you could this way change the @desc to be called as +desc or +d or whatever you prefer. This is out of the box. Changing the argument list is more complex; for this the developer need to supply something like an @aliascommand command, something that maps the players's input to the real command:

@aliascommand "@desc #1 = #2" = "@desc #1 & #2"

This (rather trivial example) would henceforth allow the player to use +desc name & description to call @desc. There is no @aliascommand in Evennia out of the box, but it would be a simple enough thing to add for the developer deciding their players expected such customization.

Now, this is not softcode. It does not offer the same flexibility as softcode. But it does offer the player the ability to change how they call their commands, changing their experience of the core functionality as defined by @desc. Could the player, say, add an echo to the room every time they update their desc? No, not without the underlying Python implementation changing. Could the developer (knowing their audience) predict this need and offer any number of callback slots for people to change and customize? Certainly - they could even parent all (player-access) commands in their game to such configuration functionality if so desired.

Now for the tarot deck. What the developer would make available here would not be a Tarot deck. It would instead be a generic "card deck" object that players could spawn and customize into a "Tarot deck" on their own: the general functionality and properties of a card deck is after all straight forward and generic. Could the developer add slots for different echoes happening when drawing specific cards? Certainly. Could the player make the drawing of a card cause in-game effects beyond an echo, like putting the room on fire or cursing someone? No, and most likely making an object with a real game-effect like that would be susceptible to cheating; it is probably not be something a player should have the right to create - it would still need a developer's (or at least staff's) input/approval on , also in a MUSH.

As you know, contrary to MUSH, Evennia requires this game effect to be done externally, in Python. Here Evennia says: Let the player, if they want to contribute, temporarily be their own developer. Using any external code tools they want they can make their modified tarot deck and offer it up to the developer using proper code sharing tools (no server access required, heck they could just post the source code directly if they didn't want to use version control). The developer can then review this, including giving online feedback etc and accept the modified tarot deck into the code base where it can now be used.

I would argue (and this is of course where opinions differ) that for the average player to extend a tarot deck beyond the customization that a developer can think of to offer, they will need to learn some more intricate programming regardless of whether it's softcode or Python.

In general I don't think a MUSH developer has any real practical reasons to dislike using external code tools, version control and code sharing resources. For them, using Evennia would mainly be a matter of learning a different workflow - a chore for sure, but one that may be considered worthwhile for Python alone (so far I've not seen any arguments in this thread that softcode as a language is a superior one).

The easy code-contribution of those more advanced players (the ones who want to make world-affecting tarot decs) is a separate, but most real concern. While Python is very easy to learn, it's a fair point that old-time players of a MUSH are more likely to know softcode than the average populace. Needing external tools (and Python which is not seen in-game) for contributing is undoubtedly a higher hurdle for them. How common those more advanced players actually are in your particular game is really what should influence the weight of this argument: As evident from the comments of various MUSHers in this thread, the assigned importance of input from this type of player varies quite a bit. But to repeat - it's a real concern that may indeed make Evennia's paradigm unsuitable for you out of the box.

To sum up (tl;dr?): Will there be things that a player can think of to do in softcode that they can't do out-of-the-box in Evennia? Yes, most certainly, at least not without implementing a softcode-equivalent running on top of Python. How important this difference is depends on the forethought of developers and just how much softcode freedom your game's average player actually uses in practice.

... Conversely, will there be things a developer can do in softcode that they can't do with Python? No. My impression is that most things are instead a lot easier, which is one of the main drives for MU*ers trying out Evennia in the first place.
.
Griatch