Don’t forget we moved!
https://brandmu.day/
Killing telnet +/-?
-
Anything that seeks to wholly replace what we have now needs to do almost everything we can do and do it better than what we have. We’re creatures of habit and are psychologically driven to stick with the status quo if the benefit of a new thing is only marginal. This is why, I think, things like Ares have worked so well. They add new methods to introduce new people to the games while having the old methods around so that those already here can join in and, eventually, transition.
MMOs were born out of MUDs, but didn’t replace them. So if you make something so fundamentally new and alien in design… it won’t feel like a MU even if it does the exact same things. A MU, to me, is almost entirely text. Sometimes it’s fancy text, sometimes it has colours, but it’s all text. If I wanted fancy graphics and pictures and all that jazz, I wouldn’t play a MU.
-
I just want a client where the GM can pipe atmospheric music at me during their scene. (And I can choose to mute it, but come on, that’d be rad.)
-
@Solstice YES! THIS!
-
@Solstice said in Killing telnet +/-?:
I just want a client where the GM can pipe atmospheric music at me during their scene. (And I can choose to mute it, but come on, that’d be rad.)
I’m having a lot of trouble thinking of anything I’d like less in a client.
-
To be fair, if MUs go totally web based, I will probably quit altogether.
The reason for this is that it seems (to me) that web-based MUs trend toward asynchronous play, and I personally don’t prefer asynch. If I get into a scene that gets declared asynch at the moment (which doesn’t happen a lot), I will completely refuse all other RP until that scene or PRP or whatever is resolved. It’s a combination of my brain refusing to wrap around the IC timelines involved in an asynch scene, plus an aversion to retconning, which could be required by an asynch scene depending on when the asynch stuff is happening compared to the rest of play.
-
@Solstice said in Killing telnet +/-?:
I just want a client where the GM can pipe atmospheric music at me during their scene. (And I can choose to mute it, but come on, that’d be rad.)
I feel like I’m mentioning Evennia too often, but Evennia’s webclient has built-in support for that!
self.msg(audio="URL")It can do the same for
videoandimage.It’s just a matter of adding a staff-side command to allow STs to message that to everyone in the room. And a player command so @Pavel can MUTE that stuff.
A friend of mine has made a few tracks for Silent Heaven, and I’m excited to add them to the game.
Game-runner of Silent Heaven, a small-town horror MU.
https://silentheaven.org -
Mind blown. I need this in my life.
-
To me, a MU is a combination of three things: Real-time, text-based, and roleplaying. Altering those three things too drastically makes things feel less MU-like, as far as I’m concerned.
So honestly I don’t care what happens on the back end (though clients are preferred. If I have a MU client open, I am in MU-playing-mode. If I have a browser open, I’m liable to get lost on Wikipedia and totally forget I’ve got a scene in another tab) so long as those three core things remain the same.
This could very well just be a case of old man yells at clouds, but it works fine as it is. Some changes here or there to make things more approachable, or easier to develop? Sure. But if you’re going to throw music and pictures and shit at me when I come wanting a text-based roleplaying experience, it’s not what I’m there for. It’s like asking for something to read and being thrown a DVD.
He/Him. Opinions and views are solely my own unless specifically stated otherwise.
BE AN ADULT -
Most of my favorite tabletop sessions, the DM has put some real effort into creating mood lighting when the time came for spooky parts, and had a selection of creepy music and even soundboarded some sound-effects.
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.
/audio off
/images off
/clouds on
/screams on -
@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?
We have the MSP (MUD Sound Protocol) already, and it’s rarely if ever used.
He/Him. Opinions and views are solely my own unless specifically stated otherwise.
BE AN ADULT -
The need here has nothing to do with telnet and everything to do with having a desktop and mobile client. MUSHes have the most similarity to chat apps like Discord/Slack, and they all have native clients. Next-gen MUs should have one too, or you lose usability. Notifications, accessibility, custom output, logging, and various other features work better on native clients, and there’s a preference issue. (I’m a slack/discord desktop client girl myself.)
A next-gen client shouldn’t use raw telnet, though, it should be API-driven.
Unfortunately there’s a mountain of technical challenges in the way of making this happen.
-
@Faraday Agreed. I use the Ares webclient as a matter of convenience when I don’t have my regular client available. I definitely couldn’t do it full-time.
-
@Faraday Right, and I don’t disagree, but telnet’s lingering ability has been to be pretty much game-agnostic. You want to add another command with a new display output? Sure! Telnet doesn’t care about anything but sending and receiving text.
With a native client (which I agree is preferable because you have so much more control), if game A wants to add portals and game B wants to add spaceships and game C wants to add an economy, well then the API for each of those games diverges and either you have to have a Super API that can somehow standardise how to add entirely new components which the system developer didn’t consider, or you end up with a client per game.
And suddenly to run a game not only do you need to be able to write Python or JS or Ruby or whatever the backend code is written in, but you also need to be able to write desktop and mobile apps, which is an entirely different skill set (and when we start getting to the mess that is iOS application publishing, an entirely new headache)
(Yes I appreciate that a lot of that complexity can be managed with cross-platform apps these days and so on, but there’s a still a host of complexity)
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.
-
@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.
