Evennia - a Python-Based Mu* Server

[Derp]

@Griatch said:

Evennia's inlinefunc system (which Thenomain refers to in the function-call bits) was never intended to be a full nestable language construct, it was meant as a way to allow coders to offer customizable replacements by safely parsing and calling functions supplied by the developer - this was meant to always be a single call, the return of which replaces the function call within the string. Any code trickery was meant to be done in that function, not in the input - the user's agency is only to choose which function to call, potentially with arguments.

Why? I mean, this is a serious question. Why on earth would you ever have a function call that you could only call with a single function, and not allow for nested function calling? What purpose would this serve? If you're savvy enough with the code to do a function call, you should know that functions could be nestable. So why not provide that functionality from the start?

[faraday]

I think it would be good to stick to the style of interpolation markers that are increasingly common in programming languages, whether that's #{x} or %{x} or ${x} or even |{x}.

That said, I'm not convinced that having a simple shortcut for some of the more common MUSH substitutions like %r would be a big deal. Ares is able to tell the difference between %r and 75% without forcing you to escape things all over the place. Given Evennia's model, something like that probably belongs in a MUSH-specific addon, though.

[Griatch]

@Derp said:

Why? I mean, this is a serious question. Why on earth would you ever have a function call that you could only call with a single function, and not allow for nested function calling? What purpose would this serve? If you're savvy enough with the code to do a function call, you should know that functions could be nestable. So why not provide that functionality from the start?

As far as the original design goes, inlinefuncs were a way to add custom text markup based on something similar to giving a ansi color code marker. Players were never intended to be able to do anything more complex with it - as mentioned there is a distinct separation between developers and players in default Evennia.
Since all advanced functionality goes into the full python function (supplied by the developer under the hood), no actual "coding" (and choosing your nesting is a form of coding) was intended to take place on the command line. Simplicity was certainly a reason as well - there is no denying that allowing for the handling of arbitrarily nested structures adds complexity under the hood (as well as an increased need to check for resource usage), and so far no one had actually expressed any desire or need for it.
.
Griatch

[Griatch]

@faraday said:

I think it would be good to stick to the style of interpolation markers that are increasingly common in programming languages, whether that's #{x} or %{x} or ${x} or even |{x}.

That said, I'm not convinced that having a simple shortcut for some of the more common MUSH substitutions like %r would be a big deal. Ares is able to tell the difference between %r and 75% without forcing you to escape things all over the place. Given Evennia's model, something like that probably belongs in a MUSH-specific addon, though.

We try to avoid {...} since this is already a templating marker in raw Python. Not that Evennia gets confused or antyhing, but when you create strings in Python code, it's a bit unnecessary to have chosen an arbitrary color marker that actually clashes with Python formatting tags (and so you need to escape it to combine them). The % is also a positional marker in Python, which is why we avoid it for the same reason. So if we are changing it, might as well pick something not used in Python - hence the suggestion of |. I guess $ would work too. But you are right that separating %r from 75% is not in itself a problem with regexes.

While you could plug in different markup if you prefered, we try to homogenize this a bit as far as default Evennia goes, to offer a sane default - which is what the current proposal is about.

[faraday]

@Griatch I think the biggest issue is that "builders" kind of straddle the fence between "players" and "developers" in terms of their use of inline functions.

For example:

[center( [ansi(b, BLUE)] [repeat(-, 10)] [ansi(g,GREEN)] , 40,~)]

Gives:

~~~~~~~~~BLUE ---------- GREEN~~~~~~~~~~

Where blue and green are shown in their respective colors.

Perhaps if your markup language is sufficiently advanced it could handle this sort of thing, but that might be more complexity than it's worth.

[Derp]

But see, that doesn't make much sense.

Okay, so I have a function r() that turns all of my text within it red. But it can only turn text red. It can't underline it. If I want to underline it, I have to use u(). But u() can't make it red like r() can. If I want to make it red and underline it, I have to create a new function, ru(). But then what about green? Well, then I would need g() and gu(). Can I make it bold on top of that? Surely you can see where this is going.

And while yes, you could theoretically provide all of that within the arguments of one function, not every developer is going to foresee every possible permutation of those things and write arguments into the function to handle that. Whereas if you provide several simpler functions that can be nested, you are in fact increasing the simplicity, because each one does a specific thing, and in combination they can do things that would take an incredibly complex function with multiple args to do together.

[faraday]

though. My point was more about the pattern that @WTFE suggested of using a beginning marker

and

or any other permutation you desire.

[Griatch]

@Derp said:

But see, that doesn't make much sense.

Okay, so I have a function r() that turns all of my text within it red. But it can only turn text red. It can't underline it. If I want to underline it, I have to use u(). But u() can't make it red like r() can. If I want to make it red and underline it, I have to create a new function, ru(). But then what about green? Well, then I would need g() and gu(). Can I make it bold on top of that? Surely you can see where this is going.

This particular example is not relevant with the current functionality, since ANSI colors work like switches. {r (which is currently the equivalent to %r) would "turn on" red until it's turned back off again with {n. This works fine to group into a {center() call if you want, or to combine with an underline ANSI instruction. But sure, your general point is true - it's not as fully flexible as a properly nest-able system.
.
Griatch

[Griatch]

@faraday said:

though. My point was more about the pattern that @WTFE suggested of using a beginning marker

and

or any other permutation you desire.

Yep, @WTFE's comments are well taken, for nesting, correctly and uniquely closing scope is very important.
.
Griatch

[Derp]

@Griatch

And see, this is why I am hesitant to consider Evennia. The general argument for it seems to be two pronged, and goes something like:

1. Python is a powerful programming language that lets you do all sorts of super neato things which

2. Provide for an end user experience that is not currently possible under the systems used now

Except that:

1. Your python structure actually takes away from the soft-coded aspects of the current game environments, restricting developing ability to only a select few and requiring working knowledge of a different programming language using a more complex and sophisticated system of markup and design than what is currently needed to play these games while, which as mentioned above leads to 'complexity issues' leading to

2. Not even being able to replicate the basic functionality that we have in the current system, which to me does not translate to an improved end user experience.

If it cannot do everything that the current environment does and then some then it is not an improvement over the current methods of working. The first thing that you need to do if you want to sell people on this thing is to make sure that it can do everything the old system did. And right now, you're telling me that nested function calls, something which are relatively straightforward and simple in the in-line language of MU's, can't be replicated in Evennia because it makes for too much complexity under the hood with the new and improved programming language.

Yeah. Hopefully you can see why I remain dubious of this.

[Arkandel]

@Derp said:

If it cannot do everything that the current environment does and then some then it is not an improvement over the current methods of working.

While that is a valid concern, evolution in the IT field requires starting from scratch. The developers of every game engine ever look at the old version and see so many things which are built on it they'd need to replicate all over again - and they know they won't right at the beginning. All those custom maps and mods won't work right away until the same creative people who created them look at the new system, realize its advantages, and (hopefully) buy in.

Now, there is an argument to be made that only difference between MU* and other kinds of game development is that there's just so many of us, we have very limited resources and we have trouble getting enough people as it is, so why not focus on enriching what we have, as archaic as it may be?

The counter-argument to that is that we have trouble getting enough people as it is because what we are using is so archaic, and as long as there's no change of paradigm things will not get better.

Do I think Evennia is it? Possibly not (it doesn't add enough to the current way of things for my tastes) but whining at people who are modernizing the underlying MU* server implementations but - the horror! - haven't implemented everything we already have after 20 years of development is an excellent way of ensuring they roll their eyes and go do something else with their time.

Which is surely a big win, right?

[Griatch]

@Derp

And right now, you're telling me that nested function calls, something which are relatively straightforward and simple in the in-line language of MU's, can't be replicated in Evennia because it makes for too much complexity under the hood with the new and improved programming language.

There is no particular technical problem with adding such functionality. We didn't have a compelling enough use-case to implement it since we don't explicitly support softcode and no user had so far felt that nesting was a must-have. With enough good arguments brought forward we might well expand the design to support it.

@Arkandel

Do I think Evennia is it? Possibly not (it doesn't add enough to the current way of things for my tastes)

This sounds intriguing! Is this with concern to softcode or are there some other respects you feel we don't go far enough/add enough at this point?
.
Griatch

[Arkandel]

@Griatch said:

@Arkandel

Do I think Evennia is it? Possibly not (it doesn't add enough to the current way of things for my tastes)

This sounds intriguing! Is this with concern to softcode or are there some other respects you feel we don't go far enough/add enough at this point?

You're still building over the telnet protocol, which was never meant for gaming in the first place and is ancient, so too many potential features are missing from the toolbox.

So I'm talking about features like using rich text without the need to run a special client (such as saaay a web browser), offering a point and click interface for certain things (such as setting +sheets), showing images, a simple interface to handle PMs and channels, etc. Then if the basic functionality is there future developers could expand and build features from that point on.

[Griatch]

@Arkandel said:

You're still building over the telnet protocol, which was never meant for gaming in the first place and is ancient, so too many potential features are missing from the toolbox.

So I'm talking about features like using rich text without the need to run a special client (such as saaay a web browser), offering a point and click interface for certain things (such as setting +sheets), showing images, a simple interface to handle PMs and channels, etc. Then if the basic functionality is there future developers could expand and build features from that point on.

Ah. This seems to be a common misconception. Telnet is only one of Evennia's supported protocols . Nothing is running "on top of" telnet: the server is actually completely agnostic as to what protocol people use to connect to it.

People can for example connect to the same server over websockets. To this end Evennia comes with a HTML5 web client and even serves its own web site out of the box (Evennia is its own web server, allowing you to use the same database for your game as for your website).

Our web client has at this point a pretty simplistic gui that mimics the telnet look. There is work ongoing to expand this and make it more pluggable. But it's really just a javascript program sending JSON to Evennia. This data does not have to be only player input but through out-of-band communication the server and client can communicate and update in all sorts of ways behind the scenes.
.
Griatch

[Arkandel]

Sure, that sounds more reasonable.

My personal barrier to entry (others might have the same issue, not sure) has always been that implementing the basic web interface over say, websockets with multiple rooms, PMs, boards, and all of that with some semblance of security baked in was a lot of work. If you guys have cleared the basics enough to build on - say, your sample web implementation is pluggable enough to make some small changes and see how basic things are supposed to be done - and things are semi-documented so playing around isn't too painful I'd take a shot at it.

[faraday]

@Arkandel Someone might accuse me of being short-sighted or a dinosaur, but I can't imagine myself ever MUSHing in a web browser. Logging, activity notifications, multi-worlding... to say nothing of making point/click GUIs for every feature from BBS to channels... Sure you could do a fancy web client to support all that but goodness I wouldn't ever want to.

I don't think having a custom app is a huge barrier for entry. MUSHes are a lot like chat clients, and you still see a lot of people using apps for chat.

[Griatch]

@Arkandel said:

My personal barrier to entry (others might have the same issue, not sure) has always been that implementing the basic web interface over say, websockets with multiple rooms, PMs, boards, and all of that with some semblance of security baked in was a lot of work. If you guys have cleared the basics enough to build on - say, your sample web implementation is pluggable enough to make some small changes and see how basic things are supposed to be done - and things are semi-documented so playing around isn't too painful I'd take a shot at it.

If you are asking about having in-client gui elements for those things then no, we don't yet provide ready-made elements for this. I plan to add a more formal javascript backbone (for the evennia communication) so people can use a standard js gui kit on top, but that is not ready at this point.

As for web page interaction, Evennia uses Django, which is a professional and very well documented web framework (similar to Ruby on Rails but for Python). Django has a package repository with plenty of things to build from. That said, I'd think all django apps will probably need some extra work in order to fit with Evennia (a MU* is after all not the standard table structure used for web).

It would be interesting to hear what kind of minimal functionality you would be aiming for in your MU(SH?) webclient gui more specifically. Not the ideal, dream set, but the minimal one (or at least minimal beyond a simple telnet-like flow of text). Most usage from the MUD world centers around things like health bars, an inventory graphic and, if people are creative, separate windows for in-game text flow and tells/look/examine/system messages.
.
Griatch

[Arkandel]

@faraday I've been using MU* clients since '93. I know what you mean - change is always an issue. We have our toys, we're used to them, and knowing whatever it is that comes next (assuming something does) won't have every single one of our favorite features - at least right at first - is a bitch. I get that.

But are you really going to miss the arcane incantations we're now using to set a +sheet in CG (with a syntax slightly different on each MUSH) as opposed to seeing a character sheet probably very close to the ones used in pen-and-paper games to fill it in? Which of the two is simpler for a completely new player who just heard there are roleplaying games and is lukewarm about giving one a try? Or, to rephrase it, which of the two is more likely to cringe, close the window and never try again?

Many of us are dinosaurs here. But you know what happened to those poor bastards, right?

[Roz]

From the perspective of someone who places ads on places like Tumblr in hopes of hooking in the younger generation that doesn't realize there's a way easier way to do this RP thing, promise, clients are a barrier to entry. They may not be huge or insurmountable, but certainly they're an extra step to getting people hooked in. It helps now that we've had some non-MU* folks adapt and speak well of the experience back to these communities, but it's definitely not nothing.

[faraday]

@Arkandel Oh, sure, in an ideal world who wouldn't want to just be able to go click-click-click and set up a character with a graphical sheet like you do in every video game under the sun?

But when you think about the user experience, IMHO it becomes a little murkier. Right now I can have multiple character windows open across multiple games, yet still have a central client to flip between them and a central notification system. The games all have a different syntax, but fundamentally they all work the same way and I interact with them in the same way. I can save logs to my desktop easily. Replicating those core experiences in a web client is going to be a challenge.

Then consider the coding experience. Somebody has to build these games. Video games have the luxury of having a team of professional developers working on them 9 to 5 (well, more like 9 to 9 to hear some of my game programmer friends talk). MUSHes are lucky to have one hobbyist programmer who also, y'know, wants to play the game. Speaking from experience, throwing together a simple command-line MUSH command is a heck of a lot easier than learning the nuances of any web framework (to say nothing of the cross-browser headaches that plague every web programmer out there).

I'd love to be proven wrong, but at this point - color me dubious.

@Roz It's definitely a barrier for entry, but I think a more user-friendly MU client and better tutorials can go a long way to help with that.