Codebase
-
So everyone's heard their coder talk about how much shit the MU* codebases all are. Sure, we make them sing and dance and turn backflips, but at the end of the day, as a Software Engineer by Profession, I find MU codebases to be frustrating, limited, and aggravating.
I have toyed with the idea of writing my own codebase in a language like Python or NodeJS for many years. I recently found Evennia, which is a really fantastic codebase ...
Evennia, and my own Jasmine (which is a NodeJS equivalent) aren't really production ready, but working with them over the past few months, I've had a nagging question in the back of my mind: will MUSH players care that it isn't Penn/Tiny/MUX/Rhost?
Obviously the immediate answer is "Of course not, as long as it behaves similarly I won't notice the difference and won't care."
But that leaves a big question: what is the definition of "behaves similarly" in this context?
So, ultimately, what I am asking is: can MUSHers live without access to SoftCode? I'm talking about things like time(), elock(), and similar.
What do you guys think? If the COMMANDS you use for everyday roleplay were available, but you could not do any evaluation other than the occasional %-substitution, would you even notice?
I would, but I'm a coder. What about the rest of you?
-
So, ultimately, what I am asking is: can MUSHers live without access to SoftCode? I'm talking about things like time(), elock(), and similar.
Yes.
What do you guys think? If the COMMANDS you use for everyday roleplay were available, but you could not do any evaluation other than the occasional %-substitution, would you even notice?
An equivalent for %r and likely %t are a good idea. New conventions for color/italic/bold/underline/etc are probably very feasible.
I would, but I'm a coder. What about the rest of you?
Before I got involved in the mushcoding side of things, I had set up a small sandbox for various friends to RP out scenes while we were waiting for various games to open.
I took MOO with Minimal.db (3 objects, no concept of players, exits, doors, rooms, say/pose/ooc/page/mail or anything, really) and stood up a rudimentary system that met their expectations well enough to get the job done. Most of them never noticed it as anything particularly different. (But then I did softcode implement all of the %-codes, including color, so...)
tl;dr I wrote code 5 miles through the snow and it worked out fine and no one noticed.
-
Thanks for the feedback, Chime!
I do note, however, that Sandboxes are a little different from full games. People tend to be more forgiving of little weirdnesses on a sandbox, because they aren't regularly trying to find RP, interact with staff, or navigate a grid on them.
-
So I've been at this for about a year now. Little over, I think. I'm fortunate in that I have an RL coach who is teaching me not only the proper etiquette and culture stuff, but also the basics of how shit works under the hood, so I'm picking up on stuff really quickly.
One of the draws for me, though, is that with MU you can make your own code to do custom things without having to nag a coder to do it, who may not do it because it's so specific, and who is already likely overworked. Plus, taking something and creating something new gives me a feeling of accomplishment. I only barely know what I'm doing right now, but I've made a couple of cool things already, and I'm really enjoying the learning experience.
That said, I don't know how any of the new stuff you mentioned up there works. I would assume that ultimately, this has far less to do with the code and much more to do with the game. And while I think that bringing in something new would ultimately be cool, I'm not sure that it's going to replace anything, anymore than all the editions of MU out there replaced each other. They just sort of get along, side by side, within the same community circles because they serve the same purpose.
See also: Photoshop/Gimp, all of the Office programs out there, etc. You can learn multiples, and have access to different things. One of them will probably never replace the other, even if they learn from each other.
-
@Loki So I've given this a lot of thought too. I dug into the Evennia code a bit and also took a look at Jasmine a few times (just enough there to get a sense of things) and the conclusion I always come back to is that it is, mostly, "lipstick on a pig". With things like roll20 and storium out there, I feel like we should be moving beyond all the old MU codebases.
@Chime and @Arkandel both bring this up as well and none of us have actually done anything about it, but I think gutting the code back-end and leaving the familiar command-line telnet connections that MU'ers are used to is the wrong direction.
So I ask this with no hostility toward the idea, but without finding any pros myself, why shuffle the back-end only to leave the front-end experience the same?
-
How would you change the front-end experience? I mean, there are only so many options for text-based gaming. It puts letters on a screen, and you utilize a specific set of commands to do specific things, many of which are flexible enough that a simple button press isn't gonna cut it. So how would you replace the versatility of the command line experience and the flexible things it offers into a format that offers the same, but different?
-
@Derp said:
How would you change the front-end experience? I mean, there are only so many options for text-based gaming. It puts letters on a screen, and you utilize a specific set of commands to do specific things, many of which are flexible enough that a simple button press isn't gonna cut it. So how would you replace the versatility of the command line experience and the flexible things it offers into a format that offers the same, but different?
Oh, the potential is enormous.
For starters its rich text versus plain text. Or being able to have common functions straight out of the UI we now use clients for (such as pasting a log into a wiki page). Or spell-checking while you type. Or a Hangouts-like tabbed interface for OOC chats instead of spammy channels and pages. Or having a point-and-click interface for sheet setting instead of the arcane commands we use today. Or being able to display an image with the room description as an option.
I could go on.
Not all of these are universally desired, of course. But they would be options, at least, whereas with telnet they are simply not.
-
Well, the log-posting thing could be do-able now. If we can pull wiki content for help files, there's no reason why it couldn't work the other direction, as far as I'm aware, and setting an image to go along with a desc is as simple as linking an image file on the wiki. Click, picture. The rest of that could be cool, though, yeah. So we're just talking about a better interface system with updated graphics, but the same text-based concept? I can get behind that.
Still, the lack of ability to softcode my own things would keep me in MU. That'd just be a side-branch.
-
Actually, automatic log-posting is a feature I consider mandatory for any new game, and not a difficult feature to implement. Most of the games I'm on now have it.
Ignoring that, I think Glitch has a good point, but I learned about two years ago that "client code" is not my thing. I absolutely encourage SOMEONE to make a good client code. Good client code should drive good server code. And in my dream grand new codebase, I would gladly accept requests for new features such as "rich text". I think that is a fantastic example of a place where MUSHes could improve. This can be done while still using the telnet protocol, though; in fact, MXP attempted to do just that (but it was arguably a failure).
To Glitch's question, however,
@Glitch said:
So I ask this with no hostility toward the idea, but without finding any pros myself, why shuffle the back-end only to leave the front-end experience the same?
Because I am a services-oriented software developer, and this is where I am personally able to make an impact. But I will gladly work with someone who wants to make a new client, and ensure that my backend service can meet any needs of the frontend client, so long as I think those needs can justifiably improve the experience for my target audience.
-
Dreaded Double Post: I say it can be done while still using telnet, but I feel it's important to clarify that I think it can be done alongside telnet. Not necessarily over telnet. Increasing features based on the type of client connecting is a positive trait; or more specifically, degrading features based on the capabilities of the client is a positive trait. It's something most web developers are quite accustomed to (anyone else have to support IE6 long after IE9 became available? I did.)
-
I would be more excited about rich text formatting if I hadn't seen the terrible things people do with ansi, css, and fonts already. What should be a feature that makes me go 'Oooooh' is a feature that makes me go 'Nnnnngah' .
Just imagine it. Comic sans and papyrus in rainbow colors everywhere.
-
@Derp
@Arkandel gave a number of potential upsides, but I think he's primarily right in that it provides options where there are none now. MU is a limited codebase that has reached, to my mind at least, its maximum potential. Also, a softcode implementation is a security headache and time sink that I just wouldn't care to deal with in order to satisfy the itch of a very small percentage of MU'ers who wanted to "code" on someone else's game. Most MU'ers just want to be able to RP and use the mechanisms that allow for an easier time of it.@Loki Last time I looked at Evennia, it had a wrapper for its sockets so that it could use tcp or websockets. Is that something you've considered? I think the biggest problem with it at the time was that it still worked off of strings in the back-end code itself (Jasmine did too, yes?). I'd prefer arbitrary JSON objects, particularly if the back-end is node.js.
-
@Glitch, I'm not sure what you mean by strings in the back end.. Evennia does use strings often as keys into Python dictionaries, but most objects are class instances or plain Python dicts.
Recently I've been working a lot with Evennia so I've got a better feel for it. It or a similar codebase definitely could drive a Storium-like UI. I agree with @Loki that you wouldn't have to leave die-hard telnet users behind (and it'd be silly to do so).
-
@Ide If I recall correctly, all commands were routed through string parsing (like standard MU fair). I'd like to pass something like (completely random example):
{ user: "glitch", method: "roll", options: { explode: true, dice: 10 }, target: 5 }
And have the back-end handle that because the nWoD plugin/module/whatever is installed and it knows what to do with that. I don't want to make an interpreter that'll catch that JSON object and turn it into "/roll/explode 10:target=5" for Evennia's back-end to parse out "roll" and send it to a roll command as a string, where it is interpreted as a string with results returned as a string just for die-hard telnet users.
If that's not the case now, this is what I recall of the last time I had poked at it.
-
@Glitch Ah OK, yes that's how it works, it's a result, perhaps unfortunate, of how Evennia commands combine parsing and execution. I think it'd be better to separate the two.
-
As long as I can code a simple multi-descer and have it work, I'm good.
-
@Glitch Jasmine uses JSON objects, but I've restarted it so many times and it's just not in a working state. I'm restarting it again in ES6 and I like where it's going right now. But yeah, it's JSON, and your example would work fine if the API was designed to handle it. That's all in implementation details, and not hard to support.
@Misadventure What if there was a multidescer already in place? Would that satisfy?
-
No.
Okay, if it worked exactly as the one I make does, then yes.
I used evals and whatever to make it so any text changes I make are passed immediately through to what is LOOKable. It's not hard, but perhaps for security reasons, every multi-descer I've seen requires reloads when you edit part of it.I'd miss messing about with code and such, but really that's not important.
I'd miss being able to make my ridiculous level of modifiable descs. EG, some of my characters wear cosmetic contacts or fake teeth, and I had sub-desc parts, for each part of the desc, and the ability to not use all parts, eg if I had a face section, body desc, clothes, demeanor, with addons for displayed items of power/weapons, I might just drop parts in any given desc set.
Yes, I like fiddling with my desc.
-
I'm actually very interested in/optimistic about Evennia, following it is one of the things that's kind of kept me out of mainstream MUdom recently. Python seems a good fit for MUery and some of its built in game-to-web stuff seems like it could be a big deal for non pyschoders who still want access to those kind of modern features (it can, for instance, publish character sheets to a website right out of the box). Now that they've got a sort of official example game project in development, it should help people jump in by providing more complex examples to look at, copy and modify.
@Glitch said:
@Loki So I've given this a lot of thought too. I dug into the Evennia code a bit and also took a look at Jasmine a few times (just enough there to get a sense of things) and the conclusion I always come back to is that it is, mostly, "lipstick on a pig". With things like roll20 and storium out there, I feel like we should be moving beyond all the old MU codebases.
I don't see how these remotely have anything to do with each other. Roll20 is a VTT. Storium (I didn't realize it's even still a thing) is basically slightly structured but still nearly freeform forum rp. Neither has much in common with the average MUX/MUSH style game at all. Unless people have hacked/converted them for radically different purposes than their design without my being aware of it, anyway.
-
@bored You don't see how a web-based VTT and a free-form story "logger" and platform have anything to do with this? Seriously?
The reason people haven't abandoned MU'ing entirely for these other options is because neither roll20 nor Storium offer the style of gaming MU'ers are familiar with, as you say. But the building blocks are there. Storium is lacking in that their system is immutable and the real-time feel is a bit lost in the "post" nature of interaction. As for roll20, it has that real-time component, but little prominence is given to text-based RP and it doesn't do a good job at handling scenes as anything more than one long log.
However, there are people that use roll20 for text-only RP (they have even recognized this by adding a text-only search option for people looking for games). It's basic, really only offering /emit, but it allows people to fold it in with the visuals of a "scene" with the rolling and combat that can accompany any PrP. Storium puts scenes into terrific order and flow and does a good job tracking the components of what could easily constitute any MU scene.
If people want exactly what they have now, then no, there is nothing that will replace it. If there's something that eventually comes out and offers things like always-on connectivity, flexible enough code to build a game around any theme or setting and the mechanics to play it? I'd certainly move on at that point.