Killing telnet +/-?
-
@Rathenhope said in Killing telnet +/-?:
I mean all of that is probably included in your mountain of technical challenges there, but it’s why I started by poking at a webapp version first, because at least some of that complexity can be shoved under a rug, for now.
Sure, I wasn’t suggesting that you shouldn’t work on that thing. I just think it’s solving a different problem.
I don’t think every game having a separate desktop or mobile client is realistic, either from a game runner’s perspective (as you said, it’s unreasonable to expect them to develop that) or from a player’s perspective (can you imagine having to download three or four different apps to play?)
But I also don’t think that having a generic non-telnet API is unrealistic. It’s not trivial, but it’s not impossible either. I’ve already started designing around this for a hypothetical Ares mobile client.
-
I was thinking about features I’d love to see in whatever communications protocol replaces telnet for MUing, and the big one I keep coming back to is:
Markdown support.
Also, if we’re talking about moving from a mostly deprecated communications protocol to a newer more robust one, what’s stopping the MU community from jumping to SSH?
Proud Member of the Pro-Mummy Alliance
-
@Pavel said in Killing telnet +/-?:
@Solstice said in Killing telnet +/-?:
That being said, creating the possibility for people to use tools or features if they want them is a far cry from shoving them down people’s throats.
Okay, but what’s wrong with sending a Youtube link or a link to a Spotify playlist or something? Why does it need to be done through the client? Why does it need to be a built-in part of the game?
I mean, nothing’s wrong with that, but it’s absolutely a different experience. Solstice is definitely talking about a sort of feature that’s very common in tabletop platforms and which I can agree is pretty awesome when a DM invests in using them. It’s a different experience getting a link and opening it vs having the DM kind of – curate and control the audio experience.
I’m not saying it should be a top priority necessary feature, but it’s wrong that there’s no experiential difference between that idea and just sharing a link.
-
@Jumpscare That’s really cool! I love anything that gives GMs more options to set the scene and atmosphere. It won’t be appropriate for everyone, sure, and people being able to mute it if they’re not interested is ALSO good.
But yeah. Bring on the revolution. Let’s do some new things and see how they go instead of spending so much time trying to kill them before they’re developed because people MIGHT not like them as much.
-
@Roz said in Killing telnet +/-?:
@Pavel said in Killing telnet +/-?:
@Solstice said in Killing telnet +/-?:
That being said, creating the possibility for people to use tools or features if they want them is a far cry from shoving them down people’s throats.
Okay, but what’s wrong with sending a Youtube link or a link to a Spotify playlist or something? Why does it need to be done through the client? Why does it need to be a built-in part of the game?
I mean, nothing’s wrong with that, but it’s absolutely a different experience. Solstice is definitely talking about a sort of feature that’s very common in tabletop platforms and which I can agree is pretty awesome when a DM invests in using them. It’s a different experience getting a link and opening it vs having the DM kind of – curate and control the audio experience.
I’m not saying it should be a top priority necessary feature, but it’s wrong that there’s no experiential difference between that idea and just sharing a link.
Sure. My main driving point, though, is that already exists. Even Beip has the capacity for it. It’s almost never used, never in my own experience. What is used, though, is sending Youtube links. Because it doesn’t require specialty code, or special tools, or anything else.
Additionally, I think if you did that with copyrighted works it would count as a broadcast… so you’d possibly open yourself up to problems there. It’s far easier and simpler to just send a link if you feel the need to include sound in a text based game.
-
So if we’re trying to just get rid of Telnet, we can actually keep a lot of the MU-code stuff we already use, we just need to adapt it to a new comm protocol.
Has anyone tried to adapt XMPP, WebRTC, or maybe Websocket for a MU server?
Telnet’s just the middle bit between the client and the server. There’s no reason to try and build a whole new set of clients and servers when we are just talking about getting rid of an old, and unsecure comm protocol. I mean, it might be as simple as reworking the clients and servers to use SSH.
-
@MisterBoring said in Killing telnet +/-?:
Also, if we’re talking about moving from a mostly deprecated communications protocol to a newer more robust one, what’s stopping the MU community from jumping to SSH?
Because it’s not really about the communication transport. It’s about the WAY that things communicate. The data they send over telnet.
The old MUSH interface is raw text in, raw text out.
That has the advantage of making the clients super dooper simple, because all they need to do is send and receive raw text. They have no knowledge of what that text actually represents. Is it a room desc? A who list? Does the player want to move? Talk? Send mail? Some clients give you some customization options, but fundamentally it’s a very primitive way for two systems to talk to one another. Next-gen clients and servers can do better and unlock features that are difficult to even imagine now because of the historical limitations.
-
Of course, which is why I mentioned WebRTC and the others as an option.
I think the future of MUing is a three part problem.
- The Clients
- The Protocols / Communication Method
- The Servers
The Clients and Servers can have a lot of variety, but I feel like the protocol should be pretty standard across all MUs, that way people can put up whatever server they want and know that they’ll be reachable by the max number of clients.
-
I’m clueless on the tech side, but I agree with everyone who has mentioned needing a client over web. Having a separate app/client/whatever is probably a 100% deal breaker for me. I already forget someone’s waiting on a pose, if it’s just one of 20 tabs? lol see you next week, maybe.
-
So I wanted to see how possible it was to build an Electron app that used a BrowserView to just load the site, giving the impression of a native client without actually needing any specific code on the client. Turns out it’s super easy!
I added a quick notification to test it and see what happens. So this first one is a standard browser notification from Chrome - I sent a new chat message from the native client, and as Chrome was in the background, it fired off a notification. Same sort of behaviour as Ares. No control over Chrome beyond triggering a notification, fair enough, can’t flash Chrome in the taskbar, or highlight the tab.
And then I thought - can I override the Notification behaviour when the JS frontend is loaded through the Electron BrowserView?
Yes.
Yes I can.
Rather than just a pop up notification I can make the taskbar flash as well (which is not standard behaviour). And of course, if I can override notifications when they’re being called through electron, I can do the same for anything else.
The upshot of that is, if I wanted to make a native client for this thing, it could be a single client that would work for every game that ran the system.
(Technical detail of the solution: when the JS frontend code is loaded through the Electron app, it replaces window.Notification with a function that sends an IPC message, so rather than sending an HTML5 Notification it fires off an event. The IPC message is then picked up by the main process of the Electron app and from there we can trigger anything we want, which in this case is just a native notification and the taskbar flash)
-
-
I know it exists, but I would love to see more clients with interfaces that automatically customize to a theme set by the game you’re connecting to. I’ve seen it playing a few MUDs in the past, but I haven’t really seen it for MUSHes or MUXes. It would be neat I think.
Is that something that would be possible with an Electron client?
-
@MisterBoring what do you mean by theme?
-
Basically all the visual elements and a bit of the organization (like the chat tabs and stuff).
My idea is that individual games could provide a CSS-style sheet type thing that would pretty up the client along that specific game’s themes.
-
@MisterBoring oh, okay, you mean like in an ares-type web portal?
-
Sure, but I think it would be neat if it also sort of stylized the client for folks not using a web portal as well.
-
@MisterBoring said in Killing telnet +/-?:
Sure, but I think it would be neat if it also sort of stylized the client for folks not using a web portal as well.
Naturally it’d be an opt-in process.
-
Totally. Could be covered by a “Load style” option in the client and some kind of optional download available either on the client homepage or maybe hosted by the games using it themselves.
-
@MisterBoring I’d definitely give some side-eye to any part of a client that automatically downloaded and applied/ran something without my knowledge. So you’d have to be careful with the implementation of it.
He/Him. Opinions and views are solely my own unless specifically stated otherwise.
BE AN ADULT -
There was a mush client briefly that was coded with interactions with a particular code base that was basically a mush except when somebody was connecting with the client made for it. Pueblo? Does anyone else remember that? There were like, 3 WoD games in the mid-late 90s that used it I think. It TOTALLY changed the UI of the client when you logged into one of those games. Popped up maps you could click on to move to and such. Please lord somebody tell me I’m not the only one that remembers this.
