The Death Of Telnet: Is It Time To Face The Music?
-
@derp said in The Death Of Telnet: Is It Time To Face The Music?:
So I assume that all aliases will be under the main help file? Or is this more invisible commands with no documentation? Not naysaying, just genuinely curious, since that is a problem that has been brought up before.
The commands themselves aren't invisible. They just sometimes have aliases that you can use if you're already familiar with the aliased version. Nobody should need to learn the aliases. If they don't know the command, they'd learn the "official" documented way. That hasn't caused any issues for people thus far on the beta games, but if it proves to be a problem, I can certainly list the aliases.
As for graphic/clickable: No offense to the designers, but Pueblo was lame. Sometimes it's not the idea that's bad it's the execution. (And yes, some may say the same about some things in Ares. That's their prerogative.)
-
Advertise your game on Shangrila MUX, and let some of the MUSH versions of RL supervillains onto your game. You'll have to have a really dark rating allowance, and the mainstream community wouldn't like it, but this has a historical precedent.
In the comics community, in the late 1970s, early 1980s, mainstream comics were the trend, and artists/authors with unusual ideas couldn't get their work seen, so they teamed up with what, at the time, were adult comic book authors, and created underground magazines. Same thing happened in the 1950s, with guys like Klaw (a pornographic magazine entrepreneur) showing off comics made by Eric Stanton and Steve Ditko (Spider-Man, Dr. Strange).
The new players are on the adult games, it just means broadening your horizons about what it means to be a creative writer.
-
@moonman
I mean, we all still MU for a reason beyond just inertia. I've yet to find anything better for persistent-world, real-time RP. If I could've migrated to Gdocs or Roll20 ages ago, I would've done it, but they aren't as good a platform for it. If anyone's arguing the contrary of that, I haven't read it.My own view of the argument, and the position I take in it is, the way we RP is unnecessarily archaic due to MUSH code's limitations and could be vastly improved and made more user-friendly.
-
@ashen-shugar said in The Death Of Telnet: Is It Time To Face The Music?:
So, I have this new feature that changes WOOF WOOF BOW WOW MOO MOO OINK OINK OINK WOOF WOOF WOOF. So what do you all think?
Anything after the word 'changes' they tend to tune out.
Because people tend not to understand our crazy coding moon-language.
I think it's worse when you say "I have this new feature that changes," and people think that's an invitation to be part of the change team.
I've done this too; I'm not innocent.
Then again, name more than two people in this thread who haven't and I'll call you a liar.
If you name the OP as one of them, I'll know that you're trolling.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
Arguments over telnet and whatever ill it does or doesn't do aside, I think there's probably at least some kind of general feeling that a modernized web version would do a lot if it could do it without totally jettisoning our more advanced text-land backend stuff. This is the route that both Ares and Evennia are taking, where you have both the text interface and a web portal, so... I dunno why anyone has a problem with that?
Also @faraday's log/RP screen demo looks really cool and I didn't realize things had come along that far. While I'm unclear how attached/detached it is from the game (ie is that roll actually pulling from the db, both sheet wise and roll code wise? it doesn't seem to use the grid but rather it's own locations? etc) I can see something like that being pretty usable as an RP environment replacement. You might need to add some OOC communication tools to replace the whole MU experience (where would we be without our OOC room/pub chan toxicity?) but otherwise it look like it handles most of what you'd need.
-
@thenomain said in [The Death Of Telnet: Is It Time To Face The Music?]
If you name the OP as one of them, I'll know that you're trolling.
It sure was Moon, absolutely.
Now exuse me as I finish writing this post...
-
@bored said in The Death Of Telnet: Is It Time To Face The Music?:
Arguments over telnet and whatever ill it does or doesn't do aside, I think there's probably at least some kind of general feeling that a modernized web version would do a lot if it could do it without totally jettisoning our more advanced text-land backend stuff. This is the route that both Ares and Evennia are taking, where you have both the text interface and a web portal, so... I dunno why anyone has a problem with that?
Because it does require duplicating a good chunk of the work if you want more than a basic web version of a normal client. Your bboards need two front-ends—one that runs in the traditional plain-text telnet interface, and one that works like a web forum. Your mail program needs two front-ends, one that works in the traditional plaintext and one webmail style. Etc.
It is basically duplication of all your UX; if you do everything just on the web, it quite literally cuts the effort in half.
a.k.a. Packetdancer (or "Pax" for short)
-
@sparks ... ok? Pretty obviously 'it does both things' means more work. That's generally an issue of backwards compatibility of any kind, that you have to have some redundancies.
But both those codebases are doing it. You have a problem with them doing it because you want them to do less work? I'm kind of confused what your comment is supposed to get across, I guess.
-
@sparks said in The Death Of Telnet: Is It Time To Face The Music?:
@bored said in The Death Of Telnet: Is It Time To Face The Music?:
Arguments over telnet and whatever ill it does or doesn't do aside, I think there's probably at least some kind of general feeling that a modernized web version would do a lot if it could do it without totally jettisoning our more advanced text-land backend stuff. This is the route that both Ares and Evennia are taking, where you have both the text interface and a web portal, so... I dunno why anyone has a problem with that?
Because it does require duplicating a good chunk of the work if you want more than a basic web version of a normal client. Your bboards need two front-ends—one that runs in the traditional plain-text telnet interface, and one that works like a web forum. Your mail program needs two front-ends, one that works in the traditional plaintext and one webmail style. Etc.
It is basically duplication of all your UX; if you do everything just on the web, it quite literally cuts the effort in half.
Not... entirely.
The interface will have to, naturally, be coded differently, but the actual data, the formatting, the functionality and various base generalizations will apply to both (or however many) interfaces you toss at it.
At least it should if you code the back-end properly.
If you have your telnet interface, then you have your web interface, and both require a near complete rewrite to get to the exact same data?
I'm sorry, but your design sucks and you need to re-think it.
-
@ashen-shugar said in The Death Of Telnet: Is It Time To Face The Music?:
@sparks said in The Death Of Telnet: Is It Time To Face The Music?:
@bored said in The Death Of Telnet: Is It Time To Face The Music?:
Arguments over telnet and whatever ill it does or doesn't do aside, I think there's probably at least some kind of general feeling that a modernized web version would do a lot if it could do it without totally jettisoning our more advanced text-land backend stuff. This is the route that both Ares and Evennia are taking, where you have both the text interface and a web portal, so... I dunno why anyone has a problem with that?
Because it does require duplicating a good chunk of the work if you want more than a basic web version of a normal client. Your bboards need two front-ends—one that runs in the traditional plain-text telnet interface, and one that works like a web forum. Your mail program needs two front-ends, one that works in the traditional plaintext and one webmail style. Etc.
It is basically duplication of all your UX; if you do everything just on the web, it quite literally cuts the effort in half.
Not... entirely.
The interface will have to, naturally, be coded differently, but the actual data, the formatting, the functionality and various base generalizations will apply to both (or however many) interfaces you toss at it.
At least it should if you code the back-end properly.
If you have your telnet interface, then you have your web interface, and both require a near complete rewrite to get to the exact same data?
I'm sorry, but your design sucks and you need to re-think it.
Yes, but I specifically said front-end. You're explicitly talking about sharing the back-end, and I don't disagree with you there.
The code that says 'give me a list of boards' and 'give me a list of posts' and 'give me the data about this post' can—and should—be shared between both; you'll find I've argued for designing systems precisely this way before, and built my boards, mail, and other prototyped systems for Evennia that way.
But even if the backend is shared between both, you will be able to share very little code between a UI layer atop that which presents it a'la Myrddin's bboard, and a UI layer atop that which presents the same data in nodebb format a'la these forums. And if you write code that just, for instance, presents a Myrddin bboard in html form as a clickable list otherwise indistinguishable from the on-game format, I'd argue you're not taking full advantage of the web format.
You're completely right on the backend side, but I stand by my statement here that most of the front-end UI work needs to be duplicated if you're going to really take advantage of the web. And if the question is why people would want web-only instead of web-and-telnet-both with everything presented in two formats, that duplication of work is the reason I've seen some people balk at that design.
a.k.a. Packetdancer (or "Pax" for short)
-
@sparks said in The Death Of Telnet: Is It Time To Face The Music?:
You're completely right on the backend side, but I stand by my statement here that most of the front-end UI work needs to be duplicated if you're going to really take advantage of the web. And if the question is why people would want web-only instead of web-and-telnet-both with everything presented in two formats, that duplication of work is the reason I've seen some people balk at that design.
I've been toying with the idea of a form of templating for this.
ergo, a method to have a generic base template code to say 'this is how I want my page to look' and then have the various other languages gobble it up in formatting.
Maybe have it in XML/JSON or something and then allow code to parse it for handling. Could find ways to enbed pre-defined encoding for specific languges as well, so a one template fits all type of environment.
But again, just something cooking in the back of my head.
But it should scare people. The same thing caused the creation of the API
-
@ashen-shugar said in The Death Of Telnet: Is It Time To Face The Music?:
@sparks said in The Death Of Telnet: Is It Time To Face The Music?:
You're completely right on the backend side, but I stand by my statement here that most of the front-end UI work needs to be duplicated if you're going to really take advantage of the web. And if the question is why people would want web-only instead of web-and-telnet-both with everything presented in two formats, that duplication of work is the reason I've seen some people balk at that design.
I've been toying with the idea of a form of templating for this.
ergo, a method to have a generic base template code to say 'this is how I want my page to look' and then have the various other languages gobble it up in formatting.
Maybe have it in XML/JSON or something and then allow code to parse it for handling. Could find ways to enbed pre-defined encoding for specific languges as well, so a one template fits all type of environment.
This sounds interesting, but it maybe hard to generalize? There are a slew of templating languages out there though, might be worth looking at over raw xml at least.
The way we on the Evennia side are going about this is to have a generic Python data format internally
("cmdname", (arg,...), {key:value, ...})For example, a simple send of a description looks like this:
("text", ("A nice place that...",), {})and the very last protocol layer translate to whichever client type wants the data. Extra info passed with the data are only used by protocols that understand it (so this could also contain instructions pertaining to gui look, window-pane-name etc).
So the protocol layer makes sure the webclient receives a JSON object whereas the telnet client receives a text string or an GMCP/MSDP instruction depending on what it supports. On the web side there is a js lib, in front of which you can put any third party js gui lib you want (our default one mimics a telnet interface).You could certainly build a single-page js app on top of this that handles bboards, logs etc, but using regular html pages seems more suitable for some of those applications. Since we are built on Django we get the web templating/db-connections for free, but this is then not directly linked to the "traditional" telnet-like output but served by it's own integrated web server. So not quite what you are referring to/suggesting there.
.
Griatch -
@bored said in The Death Of Telnet: Is It Time To Face The Music?:
While I'm unclear how attached/detached it is from the game (ie is that roll actually pulling from the db, both sheet wise and roll code wise? it doesn't seem to use the grid but rather it's own locations? etc)
It's completely attached. The sheets that you see on BSGU's web portal are pulled from the DB. When you edit your profile on the web, it updates the DB so those changes are reflected in the game too. The list of 'locations' you see is just a list of grid rooms. Having a tightly-integrated website/wiki and telnet game is what makes it cool.
It's also what makes it complex.
TL;DR; Folks shouldn't trivialize the impact that this "oh sure let's do both" idea will have on the future ability of people to create custom code for their games. It's a big deal.
Long-winded version...
Like @Sparks said - the issue is that you have to duplicate everything in your front-end. Not only is that more work (which makes coding anything more onerous), it makes the codebase twice as complicated. Instead of just MU command or Web client/server, now you have both and a shared back-end API. For me? Hey, I do this crap for a living. This is nothing. But for someone trying to learn the new codebase it matters a lot.
@Ashen-Shugar - Ares uses a templating system. But that's still not a magic bullet because the templates are different for web and telnet. And even if you share a back-end, any decent web UX is going to need some amount of processing on the client side. You can minimize it, but you'll never eliminate it.
Then there are some more subtle impacts. Let's say that you allow people to log in on the web side and submit bbposts or post to scenes. Should that person be reflected on the 'Who' list or the scene's room in-game? How? Let's say you allow a GM combat management screen on the web. How does it know when someone has updated their action in-game? How does it alert the GM to that fact so they don't accidentally overwrite someone's changes with their own?
These problems have solutions, but those solutions add work and complexity. So of course I'd prefer it if we could do just one or the other and not both. But the current MU* community as a whole flat-out won't accept web-only, and I see no point in doing telnet-only, so... here we are.
-
@alzie said in The Death Of Telnet: Is It Time To Face The Music?:
@surreality The loudest ones usually don't understand what you're doing anyways, but it's certainly not conducive to any of the developers 'give a fuck' rating if everyone keeps telling us how little they want it. Hope the project goes well.
Regarding this talk of the next version of Mu, however, what do you want out of the interface? Everyone keeps clamoring for the removal of telnet. Fine, but you're just replacing that with something else. If not telnet, it will be some other form of server-client communication. Maybe you do that through HTTP Requests, Maybe you make your own protocol (Relevant XKCD), Maybe you do it by email, Maybe you do it by wikis or forums or Maybe you just decide to do it by database queries (Relevant XKCD).
We're all talking about eliminating the data source, but that has nothing to do with the interface. People wanted HTML in Telnet, so pueblo exists. People wanted sound in Telnet, so we came up with ways to do that (IRC used a protocol command, Muds had MSP). People wanted really involved GUIs with Graphics and what not, so they made entire GUI Clients (see Batmud Client, or the many plugins for Mushclient that create GUIs for games).
So we change to another data source, the popular idea so far seeming to be a database backed RESTful front end, but what do you actually want out of that interface? What should it do differently? It's still only going to have text to display to you. How should the text look differently? Yeah, we can do some better things with CG that way, but we could do the same things with telnet and pueblo.
I'm not the old man on the corner telling everyone not to advance, but maybe we should actually talk about what we want out of the advancement? At least a semi-clear goal.
QFTFT. Again.
(Oh look. ANOTHER coder asking for a technical discussion. Good luck, Alzie.)
-
@sparks brings up a good point. People (MU*ers) will not give up their client for one or two games. If they are still playing a MUX, Rhost or Penn game, they will stay in their client.
Any client built for this, if you want to retain BOTH groups of players, has to adapt to this new platform alongside any MUSH/MUX that it works for, as well.
A point of consideration.
-
I want to point out that honest to god, we don't want the flood gates to open from these other RP communities. If we tip over to 'too accessible' (that sounds terrible, and I don't mean it like that) we'll have to readdress a lot more than the technology involved. Our games are all structured, roughly, the same way. You need a staffer for every 10-50 players, depending on how your game is set up, right?
What happens if ONE of these sites that has 10k people or more decides that what we're doing actually looks super fun and becomes a trend? What does that population do to our hobby and how we have things structured? Aside from the technical aspects of it, I reaaaaaaaaaaaally think this particular angle is a discussion we should be having alongside, because we're gonna need solutions if we DO pick up a wider appeal through all of these miracles.
Like, I am quite sure this is going to happen. You guys are smart people. Omg. The amazing things that are being done with our technology and what we have at our fingertips and the utterly just AMAZING AMAZING THINGS @faraday and @Griatch and @rook and @Ashen-Shugar and @ixokai and @Thenomain and @surreality and @Sparks and all of the rest of you guys (I am sorry, I know I have forgotten a few of the heavy hitters, I am still on my first cup of coffee) are doing...we've got solutions in sight. This problem is being addressed, it's making progress, and where we are NOW from where we were even 2 years ago is fucking INCREDIBLE. Ares and Evennia and the magic that Rhost does, the tools I have available to me as a game designer that I did not have the last time I wanted to make a game...fuck, you guys are making SIGNIFICANT progress, especially in the last 10 years or so. We're gonna get this.
What're we going to do when it does explode? I think if that topic doesn't get addressed alongside, we could actually explode ourselves out of existence the other way. ^^
-
@sunny said in The Death Of Telnet: Is It Time To Face The Music?:
I want to point out that honest to god, we don't want the flood gates to open from these other RP communities. If we tip over to 'too accessible' (that sounds terrible, and I don't mean it like that) we'll have to readdress a lot more than the technology involved. Our games are all structured, roughly, the same way. You need a staffer for every 10-50 players, depending on how your game is set up, right?
What will happen is when you already have too many players, you stop letting in new ones. If you don't know how to control growth in your community, then you're just bad at administering something. Like elite colleges that already have enough students, the leftovers overflow into their own spheres and make their own MU*'s.
What's the big concern? That some MU*'s will emerge that aren't structured the same way? I'm not sure how this is a problem. This reads as reluctance to adapt to any kind of change that isn't tightly controlled, and maybe even straight-up fear of it.
-
@sunny said in The Death Of Telnet: Is It Time To Face The Music?:
I reaaaaaaaaaaaally think this particular angle is a discussion we should be having alongside, because we're gonna need solutions if we DO pick up a wider appeal through all of these miracles.
-
@sunny said in The Death Of Telnet: Is It Time To Face The Music?:
You need a staffer for every 10-50 players, depending on how your game is set up, right?
There are a number of easy solutions to this. As @Moonman said - you can just limit how many people you allow. You could have invite-only games.
You'd be able to make niche concepts and be able to expect more than three people to show up. You could have more freeform or coded games where you reduce the staff overhead.And the growth wouldn't happen like a lightswitch. I think first you'd see a rise in the number of games, which will spread the load considerably.
But really, I don't see a giant flood happening ever. As @Auspice said back in the start of the thread, MUSHing sits at a particular niche of the RP spectrum. It's hyper real-time, super fast-paced and very "game-y". It's just not going to appeal to the vast majority of RPers.
Storium, for instance, is super accessible and even got mainstream media attention, yet the community is still rather small and easily managed.
-
So, not worth even discussing it as a potential problem that could use brainpower applied before we get there. Right-o, then.
