@GirlCalledBlu It's a lot easier if you first find MUD's honestly because chargen is for the most part automated. That's how I got my start, I found a Wheel of Time MUD and played that, then found an RP MUD and then found MU*'s and left mud's behind.
Today though with video games being what they are we're kinda like HAM radio fanatics in the world of cellphones.
Hello! Long time listener, first time caller...
@Thenomain said in Telnet is Poop:
Didn't I mention Evennia? I did. I didn't mention Ares because I don't know it's acceptance rate. Tho good on catching me out on the hyperbole. Are you ready for the support needed to change a few dozen games over to Ares? I'm ready to start coding for other games.
Yeah I was just responding to the hyperbole. Ares is still in heavy development and not ready for prime-time. So, no, I'm not ready to support changing a few dozen games over to Ares, like, tomorrow or anything. In fact, I'm not sure there's a whole lot of percentage in switching over games at all if you've got a stable game running on Penn and Tiny. The use case is more for new games. But long-term, yes, the whole idea is to support many games.
Random aside - I see Evennia and Ares on very different paths. One of my primary goals with Ares is to reduce the "Time To Hello MUSH" time that @WTFE mentioned. I want it to be an easily-configurable "MUSH In A Box" for folks who don't have any coding experience or a dedicated coder. Long-term I'd like to make it as easy as setting up a blog, complete with plugins and all. But that's a long way away.
My secondary goal is that I never want to write another line of softcode again. Ever. 
The final goal is to make the interface easier for new players. But I rank this a solid third compared to the other two. Partly because baby steps and partly because I think the veterans are the key to making the endeavor successful.
@faraday said in Telnet is Poop:
I think this article pretty much sums up the general viewpoint on telnet in the tech community these days.
One of the interesting aspects of this article and many like it is this section:
What Are The Security Implications Of Using Telnet?
You can replace Telnet there and in the following paragraphs with HTTP and the article is also correct.
@Lithium Huh. Did you play A Moment in Tyme? That's the only WOT MUD I know of. (And a complete non sequitur to this conversation.)
And yes... which is why it never surprises me that the MU* community is actually quite small. It is a rather old school method of RP. But, because we're small and have been around the bend so much, I think we do make it hard for total MU newbies to enter the community. There's a lot of assumption that people know basic commands like page, who, etc.
@GirlCalledBlu There was about a half dozen WoT MUD's back when I played them. There was a kind of quiet war going on between them as to which was the best, some still had original DIKU areas and such in them and others were full blown. I might have played Moment but I don't really recall. The one I played a lot of was Mirrors
Telnet has some issues but I feel some disparage telnet just for the sole reason that it's old.
Fact is telnet, as a protocol, is easy to work with. It's straightforward and simple to debug by just printing what the heck you are receiveing and sending in plain text. And over the years the MU* community has made a series of extensions to expand its capabilities to act as a game protocol, like MCC for compression (less important than it used to be), MXP for client-handled text markup, GMCP/MSDP for server/client out-of-band instructions etc. Flip on SSL and you can even give it some notion of security.
From the server's perspective the main problem is that many of these custom MU* telnet-protocols are only vaguely standardized, and even when there is good documentation (not at all a guarantee), third-party clients are often ignoring that documentation or present lackluster, partial support. And who do users blame if their client suddenly misbehaves with a server because their client is not following specs but the server do? They sure don't blame their (often ancient) client.
The other main drawback of telnet is of course, as mentioned already in this thread, the need for a custom client. This has a generic interface not customized for that a given game. Clients like Mudlet have worked hard to allow games to easily offer game-custom skins and settings though - games like GodWars2 have made quite impressive and easy features available this way - people playing GW2 has a Mudlet client that looks nothing like the vanilla one. Still, there's no denying that third-party clients still present a hurdle for complete newbies.
Web clients have the advantage of being almost completely under your control as a dev (I say almost since the browser affects things too). No need to worry about weird standards or client compliance - when you control both ends of the wire you can make your client work exactly as intended. That players can easily just press a website button and be in-game is a nice bonus. The drawback is that you are then playing catch-up with the features of third-party clients that have been in development for 20+ years in some cases.
There are lots of possibilties though. For example, here's a GIF example of user BattleJenkin's experimental (not yet official) web client for their Evennia game "World of Cool Battles":
This is replacing Evennia's default webclient GUI with a JS GUI library of their preference (it's using HTML5's canvas element). It offloads all location descriptions in its own window and uses light graphics and special effects to enhance gameplay. It's possible one could achieve similar results with Mudlet (maybe in MUSHclient too?) using GMCP/MSDP and a custom skin, but it's a nice indication of the possibilities.
Telnet still has a place I think, for the existing crowd/power users using and expecting the features of their particular third-party client. I believe aiming to offer web clients with features on par or better is the way forward though.
.
Griatch
@GirlCalledBlu said in Telnet is Poop:
@Lithium Huh. Did you play A Moment in Tyme? That's the only WOT MUD I know of. (And a complete non sequitur to this conversation.)
That's the one I was on. One of my first Mu*s as well.
@Griatch said in Telnet is Poop:
Telnet still has a place I think, for the existing crowd/power users using and expecting the features of their particular third-party client. I believe aiming to offer web clients with features on par or better is the way forward though.
Generally I agree, but the thing is that most of these cool new features would be highly game-specific. Even just that simple example you showed would make no sense on a game without combat, or a game that used a different combat system.
It's cool, I'm just not sure it's sustainable unless the MUSH community had a sudden swell of new players who also happened to be web developers.
@Griatch Any idea what the possibilities for integration with mediawiki are with that?
Gotta be honest, having an 'in page' client that matches the look of a page is something I'd be all over; it'd just likely be more than a little complicated to pull off with the way mediawiki functions. (There are potentially some imbed workarounds, or widgets, that could be constructed, though. Maybe. Possibly.)
While I'm not super aces on some of the specific look/effects (flashy things make something a full no-go for a number of players) the concept is A+.
@faraday said in Telnet is Poop:
@Griatch said in Telnet is Poop:
Telnet still has a place I think, for the existing crowd/power users using and expecting the features of their particular third-party client. I believe aiming to offer web clients with features on par or better is the way forward though.
Generally I agree, but the thing is that most of these cool new features would be highly game-specific. Even just that simple example you showed would make no sense on a game without combat, or a game that used a different combat system.
You are perfectly correct, and since Evennia is game agnostic, we wouldn't customize our default client this heavily. That said, I find it pretty telling that the custom gui shown above appeared within two days of our wclient development branch merging. The modern Javascript GUI tools out there are really quite impressive.
It's cool, I'm just not sure it's sustainable unless the MUSH community had a sudden swell of new players who also happened to be web developers.
I would suggest that it's at least a higher chance that a new player is a web developer than them being a telnet affectionado ... 
@surreality said in Telnet is Poop:
@Griatch Any idea what the possibilities for integration with mediawiki are with that?
Gotta be honest, having an 'in page' client that matches the look of a page is something I'd be all over; it'd just likely be more than a little complicated to pull off with the way mediawiki functions. (There are potentially some imbed workarounds, or widgets, that could be constructed, though. Maybe. Possibly.)
While I'm not super aces on some of the specific look/effects (flashy things make something a full no-go for a number of players) the concept is A+.
Django, which Evennia uses for Python database- and website integration, has a slew of wiki apps you can plug in to your website. I'm sure some can support mediawiki format if you must have that. I admit to not having personally tried any of the third-party ones myself so some trial & error would be needed - but per definition the wiki database tables would be available from within the game since game and website share the same database (Evennia is after all its own webserver).
So, while I wouldn't say that integrating a wiki is trivial it's certainly doable, and you wouldn't have to do it from scratch.
.
Griatch
@Griatch said in Telnet is Poop:
I would suggest that it's at least a higher chance that a new player is a web developer than them being a telnet affectionado ...
Oh absolutely. But I think this is where the goals of Ares and Evennia differ a bit. You're designing a framework that's readily extensible - and that includes extensible via javascript for folks who want a spiffy custom GUI.
I'm going a different direction for more of a "MUSH in a box" where you don't need to find a web developer in order to customize your game effectively. The reliance on coders and sysadmins to get a game up and running is, IMHO, one of the biggest (if not the biggest) obstacle preventing there from being more MUSHes out there.
@Griatch said in Telnet is Poop:
@surreality said in Telnet is Poop:
@Griatch Any idea what the possibilities for integration with mediawiki are with that?
Gotta be honest, having an 'in page' client that matches the look of a page is something I'd be all over; it'd just likely be more than a little complicated to pull off with the way mediawiki functions. (There are potentially some imbed workarounds, or widgets, that could be constructed, though. Maybe. Possibly.)
While I'm not super aces on some of the specific look/effects (flashy things make something a full no-go for a number of players) the concept is A+.
Django, which Evennia uses for Python database- and website integration, has a slew of wiki apps you can plug in to your website. I'm sure some can support mediawiki format if you must have that. I admit to not having personally tried any of the third-party ones myself so some trial & error would be needed - but per definition the wiki database tables would be available from within the game since game and website share the same database (Evennia is after all its own webserver).
So, while I wouldn't say that integrating a wiki is trivial it's certainly doable, and you wouldn't have to do it from scratch.
.
Griatch
Interesting. It would need to be mediawiki for my purposes, though; there are too many far-too-useful extensions and functionalities to it that are generally not present anywhere else.
Yes, it's a fair point, and focusing on a given genre of text game may indeed offer an easier way in for users only interested in that particular genre. If you are planning to offer a web client as well though, I think you'd be wise to make it as easily extendable as possible - the amount of web-dev knowledge out there is so vast that you'll never know what users will want to do with it.
MediaWiki is pretty comprehensive, yes. There are django authentication backends to mediawiki, but I don't know exactly how that works. Here's anyway an example of a running django-driven wiki. It uses Markdown (like musoapbox does) https://demo.django.wiki/ - not as comprehensive as mediawiki + plugins but probably useful for many a use-case (I know we'd not need anything more for Evennia docs at least).
.
Griatch
@Griatch It isn't just the markdown I use, actually. I do a lot of template creation, and use an unholy lot of DPL. While there might be other workarounds or methods with more direct integration, those work and work incredibly well to make the information accessible wiki-side. (Also, semanitic mediawiki and forms. Forms are a big thing from the wiki interface end.)
Oh fucking well.
We might be drifting off-topic here, but this is interesting. Do you have a link to a wiki of yours I could look at to get a feel for the stuff you are doing with it?
.
Griatch
@Griatch Take a peek at BITN's -- not everything is working quite as planned there, but that's just the tip of the iceberg.
bitnmux.com is the link.
The various faction lists and such, along with the character listings, all auto-populate and so on, as people make changes.
It makes an enormous difference in how the data is organized and presented, and how much direct maintenance is required. The DPL caches only update once a day behind the scenes without a manual refresh (which is not necessary unless someone is bitching that something hasn't shown up yet in which case I just do it in seconds), but once it's set up, there's no need for someone to go through and edit or adjust the pages every time something changes. Hugely helpful.
Oh fucking well.
Cool page, lots of nice features there!
With "auto-populate" I presume you mean that the lists update when people make changes in-game - and vice versa. Do you have a feel for how much change happens dynamically from in-game (updating the wiki page from the game) compared to using the web interface to change things (update the game from the wiki page)?
.
Griatch
@Griatch They don't make the changes in game, but on their own personal wiki pages. When they change their personal page, the change flows through the rest of the wiki without any need to go through and update all the other lists. (Super helpful not having to track that down when data appears in multiple places.)
One of the things you aren't as likely to see are the forms to generate the character pages (or location pages/etc.) since I'm not sure if they're visible without a specific login to edit stuff. (I can make you one if you'd like to peek. 
) For folks who are unfamiliar with making pages or wiki markup, it's a huge help.
It also ensures the data is presented in a uniform fashion (and with drop-down options, it means things like a typo here or there aren't going to be as much of a problem as it could be) which helps create the lists/gives the pages themselves the equivalent of attributes that can be referenced elsewhere throughout the site/etc. which is pretty huge.
It's pulling things from/pushing things to the game that's been... not something that happens much. The news files are written on the wiki and pulled over to the game, which makes edits/quick changes/additions far easier. I'd love to have similar functionality for more complex things, but we don't have that (at the moment, honestly @Thenomain worked a miracle just getting us that far as it is).
But, essentially, that's why 'working with mediawiki itself' might be something to peek at, or nudge some developer toward peeking at. Reproducing all of that would be a nightmare for one of the native django-wiki developers, I'd think, since they all are aspects of things dozens of people have cobbled together over about a decade.
Oh fucking well.
I'm with @surreality that trying to make a custom wiki with all the expected functionality is probably a bridge too far. I use wikidot mainly, but it has a lot of the same functionality with dynamic page lists and auto-updating. But again, that's auto-updating from within the wiki, not updating from game-to-wiki.
Having explored it a little in the past, I think that game-to-wiki is going to be tough. Both mediawiki and wikidot technically expose apis, but they're muddled, incomplete, and - in the case of wikidot - require a paid account.
Thanks for the explanation. So the way I understand the common use case, it is that you want to update, say a character data block and make sure that updates wherever it appears on your web page. Same with other data elements like factions etc. Here's how I envision a similar functionality could be integrated with vanilla Evennia:
Distributed change is simple enough - one can build a simple django app to do that rather simply (this is what Django does after all) - it just uses the same database model for the given data wherever, which guarantees it updates everywhere. You will as an added bonus have direct access to said data inside the game already with default commands to read/write it.
This would likely not be represented in the browser as wiki syntax however. Instead the user would be presented with web form (as flexible as you want it) that the user fills in and updates (that form could easily handle markdown etc as needed). Data created this way could be inserted in other pages (including wiki pages) but would not be updated from the wiki page explicitly.
Using a form is not as elegant as DPLs, but works pretty much out of the box with a little work. There may be better solutions involving mediawiki itself somehow, but I'd prefer to not have to integrate that huge mass of tables into a game if possible. If one could handle the game-specific updates with forms, then one of the normal Django wiki's might be enough for maintaining lore, rules, help etc, maybe?
.
Griatch
@faraday said in Telnet is Poop:
I think this article pretty much sums up the general viewpoint on telnet in the tech community these days.
One of the interesting aspects of this article and many like it is this section:
What Are The Security Implications Of Using Telnet?
You can replace Telnet there and in the following paragraphs with HTTP and the article is also correct.
