Evennia - a Python-Based Mu* Server

Thenomain

You have been talking High Technology, but I don't think you have been much on the path of "just learn Python, duh". Among my reasons for my direct reply were asking the poster to pull those below him up with knowledge.

A multidescer in Mushland implies three things. One is a series of commands to store text by category and name (top.manshirt) locally to the current login object (character). The second is to intelligently display these options in legible, pretty output, again for that object's instance. The third is to apply any combination of same to @desc, with the same expectation that the command's enactor and the target are the identical.

Finally, all this without needing to ask permission from the person who controls the main code repository. It's your character object's code, with all the limitations and accesses that are reasonable for it to have.

This is hard to explain on a tablet, because I can't clean it up. Hopefully this clarifies a bit from your solution.

Griatch

@Thenomain said:

You have been talking High Technology, but I don't think you have been much on the path of "just learn Python, duh".

Good, I'm glad to hear that.

A multidescer in Mushland implies three things. One is a series of commands to store text by category and name (top.manshirt) locally to the current login object (character). The second is to intelligently display these options in legible, pretty output, again for that object's instance. The third is to apply any combination of same to @desc, with the same expectation that the command's enactor and the target are the identical.

Finally, all this without needing to ask permission from the person who controls the main code repository. It's your character object's code, with all the limitations and accesses that are reasonable for it to have.

I don't include all the functionality you mention in my (long, long) post above, but I explain how the subset of @desc functionality @Derp mentioned could be added by the developer for the benefit of the creative player also without softcode. All of the three things you list can be made player-interactive without admin input. I'm aware this solution is not softcode, nor attempting to offer as much flexibility as softcode. My point is just that for many (if certainly not all) common player conveniences, softcode might not be the only solution.
.
Griatch

Glitch

@Derp said:

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.

Community "values" got thrown around a lot in the OR thread, but I'm going to actively disagree with this. The large scale contributions you're talking about are generally shared between game coders (or in the case of @Thenomain, are the same coder), which wouldn't be an issue for two games running Evennia. Secondly, while there are people that enjoy developing small bits of personal code, they're hardly the majority. Beyond some aliasing and some copy/paste code a friend gave them, I'd even put them in the very small minority.

So no, there is no direct path between MU* and Evennia, but lacking a feature that allows "untrusted" coders to tinker is hardly the platform killer you're suggesting. Personally, I think Evennia goes too far as it is in supporting a MU* like experience.

SparklesTheClown

I will say this, from the perspective of someone who is on the far end of the newbie spectrum of code? I find the idea of learning Python to be way simpler and more appealing than scaling the wall of, say, MUSH code. It's not that MUSH code is more difficult, it's just that learning it never really felt all that intuitive to me. I feel like I could just up and go start learning Python and applying it right now if I wanted to, because there's a million resources. If one doesn't work, I can try another.

But as far as the subject at hand, I've never really seen player-side code fundamentally change an entire game? Except the controversy surrounding the random name generator on Match of the Millennium >_>.

It seems like more of a luxury than anything.

Griatch

@Glitch said

Personally, I think Evennia goes too far as it is in supporting a MU* like experience.

This is an interesting viewpoint. Always interesting with feedback! Would you mind expanding some more on what you are referring to?
.
Griatch

Glitch

@Griatch I looked at Evennia once about a year ago, so you may be able to address this if you believe I'm wrong, but Evennia treats strings as first class. Its command structure is based on parsing strings for commands, moving strings around, string manipulation and then a string based response. OOB is sort of tacked on as part of a string prefix, so yes, I could parse it on a front-end, but all back-end processing is too string-based for me.

This is required for the MU experience, but makes it little different than a MU server in yet another language (though I agree a much more approachable language).

Griatch

@Glitch

Ah. If I understand you right, this is not really a correct assumption. Evennia's command structure is a completely class-based thing. Commands are generally identified by strings yes, since text is generally what is coming in from the player, but Commands are very much Python object instances and are manipulated and handled as such - you group and organize Commands using class containers and you can even move Command instances around and apply them to different objects using Python constructs.

Evennia's OOB operations use OOBCommands internally. When sent over telnet these instructions are delivered through telnet subnegotiation - these are byte "strings" because of how of the OOB protocols are defined, but once the telnet protocol has decoded it, what goes into Evennia are Python structures and the OOBhandler deals with command calls to Python functions (OOBCommands).

The in-built webclient does currently use an "OOB" prefix in order to instruct the server that what comes next is not normal player input but an OOB JSON command structure. We will be changing this internal protocol soonish to use JSON all the way as well as make the webclient a little more code-pretty than it is. This doesn't change what goes on under the hood though.

We obviously need to parse strings coming into the game but at no point are we using strings as some sort of internal main information carriers.

You even send OOB commands directly with the main msg() method from commands - the normal form is something like caller.msg("Hello world"), but you can also do caller.msg(oob=<oob command instruction>) to send an OOB command to the client of caller.

Does that address the question or did I misunderstood what you meant?
.
Griatch

Thenomain

I like the term "un-trusted coder" for the kind of coding we're talking about/hashing back and forth concerning. Running user-instanced, in-trusted code.

Kassien

So. Being one of those, that is not a programmer or have any sort of programming background, I hope I'm not interjecting with the wrong view of the conversation.

So, I'll use the multidescriptor as an example. I've actually have this set up on my game current. With an altered version of the out of the box @desc command, set up as my own command/command class. It allows a player to use switches (Which come programmed out of the box with Evennia), and arguments to set 3 different sub-descriptions to their character object, save them, list and recall them, and set saved ones to their character.

Now, I probably did this very sloppy and probably isn't the best methods for Python, but I have to agree with @Griatch, which he said (to paraphrase), that on a developers side there is nothing that Python can't do that that Softcode could do.

And I'll make this offer. If anyone wants to log in to DSMush and see how we've done things there as we are starting to build and develop, please do so, I'll answer what I can and show you what I can of how I've learned Evennia works.

acharles

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.

TNP

I really haven't read through this thread. I'm only a very basic coder and have no real interest in learning more. But I do have one question/comment.

Right now, literally anyone can open their own Mux and run a game. Some basic commands that are out there, build a grid, done. Cgen has always been the biggest hurdle but I once played on a game where character sheets were posted to a webpage and weren't on the game. They could also be put into a basic &note of some sort if you wanted. Or you could borrow someone's existing cgen and tweak it to fit your system. You didn't have to be a great coder. It didn't have to be efficient or elegant. It just had to work. But the point is, you could make a game for any genre you wanted.

With Evennia, it sound like you need to be a semi-professional programmer/game developer to make a game. And if that's the case, the hobby dies because it's built on amateur hobbyists enthusing about their favorite genre/game system/book.

So is this the case or can any GoT fanboy decide to take Evennia, install it, (and for the sake of argument borrow an existing cgen) and open a game within a a couple months?

Kassien

@TNP said:

With Evennia, it sound like you need to be a semi-professional programmer/game developer to make a game. And if that's the case, the hobby dies because it's built on amateur hobbyists enthusing about their favorite genre/game system/book.

So is this the case or can any GoT fanboy decide to take Evennia, install it, (and for the sake of argument borrow an existing cgen) and open a game within a a couple months?

So I disagree. I'm a project manager for a facility by trade, and didn't know a lick of Python before I switched to Evennia. I knew very little about Computer Science in general, besides how to maybe put components together, install software, etc. I would say there are some hurdles to over come that would be so much easier with as professional programmer. But I originally tried to start my game in TinyMUSH, TinyMUX, and PennMUSH. I couldn't figure out MU softcode at all. I had a professional programmer look over MU Softcode and he couldn't figure it out really either.

But when I switched to Evennia, I found Python much easier to learn. Not to mention that the resources to learn Python are significantly easier to find than the hack of language MU Softcode ran on. With Evennia, and Python in general, I've actually have a chance to open a game.

Griatch

@TNP

To add to the comments of others; Evennia runs out of the box, complete with database, a website and a webclient (as well as traditional telnet and so on). After install you have a fully functioning, if empty, game with some 90 default in-game commands for building, emoting, chat in channels and so on. If you want you can open it up for others to come join you. It's completely generic, no dependence on any genre or even game style at this point.

You could now, as you say, build a grid and be done if you are going for the very simplest type of casual game. New commands are not added in-game, but instead by editing a file in a text editor. And the language is Python instead of softcode - those are basically the only differences at this level of commitment.
.
Griatch

Derp

@Tirit said:

But when I switched to Evennia, I found Python much easier to learn. Not to mention that the resources to learn Python are significantly easier to find than the hack of language MU Softcode ran on. With Evennia, and Python in general, I've actually have a chance to open a game.

This may be the case. Python absolutely could be easier to learn.

But resources already encoded in python for the games that are extant are going to be slim to none, whereas there are tons and tons of things for MU out there already. Glen Morse's page comes to mind, and has a crapton of things in it. Thenomain has things on his own thing he's shared with all of us. MUX2 comes with SGP. Etc.

I think, like @TNP, that not being able to experiment, add, and freely contribute without a coding overlord approving it and updating it, as well as the lack of customizability, is going to be a thing that keeps this from being a big thing. It'll just be one more fork of a thing that a handful of people use because they prefer that system.

Until you can figure out how to out-of-the-box offer a way for players to run their own things (within certain permission levels for information they should not be touching) you're not going to replace anything, or be the future of anything. You're going to be one more branch of the tree that struggles to hang on there.

Edit to Add: Think of it like this. I've been using notepad for all of my word processing for ages and ages. It doesn't have a lot of features, but it gets the job done.

Someone comes along and tells me about Microsoft Word, and all the bells and whistles and things with it. Except, in their design, they forgot to add a functionality for copying and pasting. To me, it doesn't matter how awesome the new thing is, or how many shinies it can do, if it cannot duplicate something that the previous system has had for what, thirty years?

That's how I feel about Evennia and the things we're taking about. I don't care how cool python is or what it offers, you are telling me that out of the box it cannot replicate something that is currently offered under the system and has been for many, many years.

I don't think I'm the only one who's going to feel that way.

TNP

So the next question would be, can they import an nWoD cgen into their game from someone else's? And how easy would it be for them to write one from scratch (which, granted, is not easy for Mux code either or more people would do it).

Thenomain

@acharles said:

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.

That's like saying coding a blog in PHP has a non-trivial learning curve so you might as well learn Ruby-on-Rails and Apache installation.

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. The people you are reaching with this already agree with you. Which is to say, the choir is with you; the congregation is (handwaves) over there. Unless your point is telling people to "cope" and why they have to, in which case yeah, we get it.

@Griatch: Can Evennia be connected to via plain Telnet client, or is the Web client built-in to the install? I mean, can I troubleshoot on my Mac without having to turn on the web server? (Yeah yeah, I could check this out. I ask questions like this to remind myself to check as much as to expect an answer.)

@TNP said in Evennia - a Python-Based Mu* Server:

So the next question would be, can they import an nWoD cgen into their game from someone else's? And how easy would it be for them to write one from scratch (which, granted, is not easy for Mux code either or more people would do it).

Give me some time, already! I'll answer Griatch before he answers you more completely, but to put it in simple terms yes, you can pull someone else's library into your system.

Hm; is there a "requires" setup? I would like to write a more general framework that might not be packaged with every ThenoVennia library.

Griatch

@TNP

So the next question would be, can they import an nWoD cgen into their game from someone else's? And how easy would it be for them to write one from scratch (which, granted, is not easy for Mux code either or more people would do it).

I'll leave this answer up to the MUSHers who are already using Evennia for WoD. Hopefully one will reply.

@Thenomain

You can connect to Evennia via plain telnet (but it's of course better to use a dedicated telnet mud client) and the web client is built into the install. Evennia is actually its own webserver, so you get a default web page out of the box, connected to the same database as your game.
.
Griatch

Thenomain

@Griatch said:

Evennia is actually its own webserver

I figured this would be the answer, as much as I was hoping it was true.

DOES IT EVEN JAVASCRIPT?!

Griatch

@Thenomain said:

I figured this would be the answer, as much as I was hoping it was true.
DOES IT EVEN JAVASCRIPT?!

The webclient is a pure HTML5 application using websockets with a fallback to AJAX for older browsers. So yes, it's a pure javascript app, communicating with Evennia over JSON. Admittedly our webclient is not as "clean" internally as it could be yet, but we are working on it to make it easier for people to expand on it in a more modular way.
.
Griatch

Volund

@TNP said:

So the next question would be, can they import an nWoD cgen into their game from someone else's? And how easy would it be for them to write one from scratch (which, granted, is not easy for Mux code either or more people would do it).

@Griatch said:

I'll leave this answer up to the MUSHers who are already using Evennia for WoD. Hopefully some of them will reply.

I'm working on EXACTLY THIS. And so far, so good.

But let's shine a little more light on exactly what that means.

Q) Can you run MUSHcode on Evennia?
A) No, but Python is objectively more powerful and widely supported than MUSHcode.

Q) Can you directly translate MUSHcode into Python code?
A) No, but much of the logic established in a MUSHcode project can be replicated in Python with considerable ease. That's not to say it doesn't take time.

Q) Can you import nWoD cgen from one game to another's?
A) Yes, although not necessarily the way you're thinking. In MUSHcode, you'd create an object, give it the right permissions, ensure the right attributes were admin-locked, make some rooms for chargen and call it good. maybe. The concept is similar in Evennia. Download some .py files, import them, link the proper commands into your default character cmdset (how commands are assigned to players) and you're good to go. The concept is similar, although the methods vary wildly.

Continuing the last question: Python is in fact BETTER than MUSHcode for this in a sense, because in MUSHcode you have to ask the questions 'well, this will run for TinyMUX, but what about PennMUSH or X or Y.' Python is just Python, there's no fifteen variations of Python, so in this sense you can MORE READILY take a project from one person's Evennia game and import it directly into another. The downside is that everyone's specific game implementation will be different - one person's idea of nWoD chargen might be entirely some commands, whereas MY idea of it involves an nWoDCharacter class that inherits from a StorytellerCharacter class that inherits from Evennia's Character class (StorytellerCharacter also being the foundation for Ex2Character and Ex3Character for Exalted...)

My personal approach to this is MONOLITHIC - I want my implementation to be fully self contained and standalone, so it may not be that easy to just 'add my nWoD stuff to some random Evennia game.' It's similar to how you'd basically build a game AROUND Thenomain's WoD code used at the Reach (at least I believe it's used there. Never been to the Reach.)

Also I am having GOOD LUCK with implementing things from Exalted and nWoD so far in my own style... and my style doesn't HAVE an extensive database of Charms, Gifts, Disciplines, etc, and all of their specific sub-rules. It's merely a toolset for constructing and managing sheets with some extra features. If anything it will be -easier- to design lists of powers and pre-req checking, automated XP spends, and that kind of thing in Python. That will require more skill than I presently HAVE, but I'm learning as I go along.

Furthermore, it has proven not at all impossible to import a PennMUSH database using my MUSHcode implementation of Exalted and nWoD directly into Evennia. It took me just one day to figure out a good way to parse the PennMUSH outdb and read data into Evennia. Other MU* server flatfiles might be more challenging but the concept can likely be re-applied.