Alternative Formats to MU

Lotherio

Dice and combat resolution ...

This is a big part of the discussion I think. There needs to be some standard of interface that recognizes the system choices made by the admin. Even if as a 'user' the admin must still learn code, the UI for the player still needs to work with the game system of choice.

I mean, honestly, wasn't that the entire point of going from MUD to Mux to MUSH to whatever, more players could softcode while playing inside the box to accommodate whatever system was floating their boat that day?

Sparks

@rook said in Alternative Formats to MU:

What is being discussed here is design for the server, not the protocol.

I think the idea is a server which is no longer beholden to telnet at all, which is why "telnet" is still a relevant term here.

The old Pueblo-enabled servers—and even Ares and Evennia, presently—have a design requirement that whatever they do must also be accessible via plain old boring text-only telnet. Thus even in that world, telnet is still a consideration in everything you design; everything has to be accessible to that lowest common denominator. You can't make channels work solely like Slack or Discord, because you still need to be able to interact with them via telnet in SimpleMU. You can't even make those channels support multi-line text cleanly (something you can do in, say, Slack or Discord), because you still need to be able to spawn them on old legacy clients, and only the first line would be slurped into a spawn. Etc.

This also means that Evennia and Ares' web clients tend to look very like telnet, because that's the easiest way to support things.

A complete redesign—something that does away with the telnet requirement—is not constrained by those same limitations.

Roz

@auspice said in Alternative Formats to MU:

@glitch said in Alternative Formats to MU:

@auspice Yes, your anecdotal evidence is the correct basis for all the factual statements you've made in your posts so far in this thread. The sheer disrespect and dismissiveness of those not in this hobby, but perhaps interested, matched to the misplaced sense of writing superiority, is infuriating. I'm obviously of the belief that telnet is no longer where I'd like to see the hobby go, but when you adamantly state it's not for you, I can't say I'll be sorry if that turns out to be true.

Someone more even-tempered at the moment might suggest that they hope you're so impressed by new developments that you change your mind, but I think your attitude toward new people will only ever be detrimental. And I'd rather take my chances with them.

This is the most politely worded "Fuck off" I've ever received. Thank you for your time and effort

I support Faraday's efforts on Ares and the web portal. We've had arguments on it, yes. And some things still frustrate me. Even with the web cg. I wish that was all on one page or didn't require reloading between tabs, but it's getting there (I know it's still in development, after all).

But a lot of her work is actively in support of RP and not just for the shiny. That's what I'm trying to say. I don't want change just for the sake of change. I want to see things developed that encourage and enable rp.

I hate logging. I always have. I do not log. I do not edit logs. I do not post them. You have to really pressure me. Except with her scene system. I love it. I sing its praises. And that love goes beyond the logging. I hate big grids. I think people need more freedom to pick where they rp. More flexibility. I get lost on grids and when there's only a few rp rooms, all full... It's like fuck, now what? I'll lose my desire to rp before I ever get oriented. Her system gets rid of that issue.

She's made solutions within the framework that has encouraged more role play. The thing we're here for. I support this.

Honestly, my impression is that you believe Faraday is doing work to help encourage RP because you've experienced her stuff after the fact, but you're characterizing other discussion about new platforms as "just for the shiny." And I don't know why. I feel like the people who are trying to discuss how a new system could look have been doing so from the stated perspective of "how can we make MU* RP more user-friendly and intuitive," which I would say are goals to help encourage RP. To have you repeatedly characterize things as us just chasing shiny or doing new for the sake of new is the reason why I've been so frustrated -- and, frankly, insulted. Because you've been insulting. (I mean, saying that new efforts want to exclude people with disability? That just wasn't necessary.)

It's one thing to bring up "Here are issues that I worry would get left behind in new development," it's another thing -- well, say it how you said it.

@rook said in Alternative Formats to MU:

You're right, but if we're honestly talking about something to replace telnet, I think that our 'core' needs to be broader than 'every game uses this'. It needs to have a full enough list of features that people go 'that looks better', and that's going to include, IMO, logging and conflict resolution.

Point of order... I am confused by the constant usage of the word 'telnet' in this conversation. Telnet is a protocol, like HTTP or SMTP or SSH. This misunderstanding has clogged a lot of this conversation from a technical perspective.

I think the better term to be using here would be 'server codebase', which is the application like PennMUSH or RhostMUSH or TinyMUX or AresMUSH that people are logging into. That is what provides the features that you are discussing.

Not picking on anyone, but please. Unless you are speaking to the specific carrier protocol that people use to log into the server, don't use the word 'telnet'.

When I've been using it, I have indeed been speaking about the specific carrier protocol, which is one of the things limiting development.

faraday

@rook --

@sparks said in Alternative Formats to MU:

The old Pueblo-enabled servers—and even Ares and Evennia, presently—have a design requirement that whatever they do must also be accessible via plain old boring text-only telnet.

Yes exactly. If you want to be pedantic from a tech perspective, it's not telnet the protocol that's the limitation, it's backwards-compatibility with existing telnet-based clients. Or, for short, "telnet".

@roz said in Alternative Formats to MU:

Honestly, my impression is that you believe Faraday is doing work to help encourage RP because you've experienced her stuff after the fact, but you're characterizing other discussion about new platforms as "just for the shiny."

Yeah, I mean... I got a ton of push-back early on for the things that people are now enjoying, but it all started from the same place: How to make things better both for existing players and for new players. It's all driven by real use cases. People I've spoken to and their needs. Not just "Oh hey, a new shiny tool to use". Now not everyone has the same needs, and sometimes meeting one person's needs shortchanges another's. That's just life traveling west in the tech world. You can't please everybody.

Personally, I see more people -- long-time MUSHers, not these hypothetical masses waiting just beyond some barrier - bemoaning "I just don't have time for four-hour scenes every day but I still love the MUSH environment" or "Aww man I can never make it to plots at the scheduled times" or doing G-docs RP when they can't make it online than I do people lamenting that they'll get too distracted by moving things to the web. That's not to discount or diminish the latter's point of view. It's just numbers.

Apos

@faraday said in Alternative Formats to MU:

Grid/movement would be gone. Choosing/changing location is just an integral part of conducting a scene.

That's what I meant when I talked about a paradigm shift instead of just slapping a web UI onto the current MUSH commands.

As for the UX? You’ll probably want a chat window at the bottom/side of your screen at all times because that's so important. Forum and Scene are things you would use separate tabs for depending on what you felt like dealing with.

And oh-by-the-way nothing stops you from having several tabs for different scenes just as you’d have different windows open in your web client. Difference is - you can do multiple scenes with the same character. No more spoofing or silly OOC puppet nonsense. So many clunky things that we're required to do because of the telnet client restrictions just fall away.

I think in possible next gen approaches there would be splits here due to philosophical differences in approach and implementation of the kind of game. I really admire the approach you have for Ares and particularly scenes, but I think I would have to branch in a slightly different direction to capture the feel I'd want.

There's a strong coded emphasis on continuity and a lack of handwaving or abstraction inside more RPI like games that I find extremely flawed but I do think it creates a more immersive, organic environment, and I lean closer to capturing what I see as positives for that while trying to avoid its pitfalls.

For me I'd have to design it in a way where I can answer questions like, "What are players doing on their characters in between the scenes they want to have happen?" and, "Can a scene spontaneously start around them without really intending to while they are doing that thing?" And I think those possibilities would be eliminated without me taking a different tack. Obviously this is a personal taste thing, and not saying what you're doing is in any way wrong, just how implementation might differ wildly based on feel we'd want to see.

saosmash

I love the idea of both random organic RP springing up AND being able to RP more than one scene at a time on the same character. Is there a way that these perspectives can actually be combined? Like, what if I have a PC object that I can ghost around on crashing into randos AND somehow can spring off a scene in a different window on the same character and RP it out while that is still happening?

Apos

@saosmash said in Alternative Formats to MU:

I love the idea of both random organic RP springing up AND being able to RP more than one scene at a time on the same character. Is there a way that these perspectives can actually be combined? Like, what if I have a PC object that I can ghost around on crashing into randos AND somehow can spring off a scene in a different window on the same character and RP it out while that is still happening?

Actually yes. By specifically denoting any previous RP as having a previous continuity, with preset consequences that would already be reflected on anything current. So you could have a core continuity, where unexpected events can happen (like character deaths), and previous ones for fleshing out scenes but knowing that nothing could happen in it that would yield unexpected impact on current scenes.

In other words- one main scene, and any other scenes would either have to be fluff, or unable for other reasons to impact current RP except in terms of information.

saosmash

@apos Ugh but fluff is terrible. What if I want plot relevancy in all of my RP? Why can't I have all the things?

Apos

@saosmash said in Alternative Formats to MU:

@apos Ugh but fluff is terrible. What if I want plot relevancy in all of my RP? Why can't I have all the things?

I dunno if fluff is quite right though. Maybe we shouldn't look at it from a technical implementation perspective but a story perspective. Right now most MUs that allow proxies/puppets/whatever in multiple scenes have the strong understanding that it's not like someone is going to randomly drop dead in them and have them have to explain that to every other scene that character is in. The scenes can be exciting and fun but they cut away that organic element slightly, even if it's not really emphasized. The problem is making it explicit kind of starts to destroy the illusion that anything can happen, even if it might not have really been the case.

saosmash

@apos I mean, sometimes I'll randomly take damage in the middle of a scene from a storyrequest and I usually just wait until the scene is over to RP a new one about the fact that I'm vomiting blood. There's usually room to be at least a LITTLE flexible.

Apos

@saosmash said in Alternative Formats to MU:

@apos I mean, sometimes I'll randomly take damage in the middle of a scene from a storyrequest and I usually just wait until the scene is over to RP a new one about the fact that I'm vomiting blood. There's usually room to be at least a LITTLE flexible.

Yeah, like I definitely am not a fan of going the full on simulation approach of some RPIs, which while immersive I often find miserable. It's just tricky getting just the right amount of handwaving that won't bite you, especially if you allow PVP in games and someone can feel another person is basically cheating by doing way more than they could possibly do. I don't have that kind of environment but on like a half dozen occasions I've still gotten mighty salty complaints from people mad that other characters have had their names up in lights so often and felt it wouldn't be physically possible for them to be in multiple places, despite repeatedly saying I'm not interested in enforcing that kind of strict timeline for travel yet.

faraday

@saosmash I don't see how organic RP and multiple scenes are inherently in conflict. Someone can 'open' a scene in the mess hall and leave it there, hoping others join in for "random RP" while still doing a back/forwardscene in another tab with someone else. You just have to sort out your character's internal continuity and work out where any given RP fits in. That doesn't mean other scenes have to be fluff, just that there are some constraints to what you can and can't do without causing massive retcons.

@apos You're never going to stop people from doing multiple scenes on their character, backscenes, etc. People do that already; the only difference is that they're using crappy workarounds (like OOC alts or spoofing one char with another) or going off-game to G-doc or whatever.

That said, if a given platform doesn't let you execute your vision, no biggie. That's why it's good there are multiple platforms to choose from.

surreality

@saosmash said in Alternative Formats to MU:

I love the idea of both random organic RP springing up AND being able to RP more than one scene at a time on the same character. Is there a way that these perspectives can actually be combined? Like, what if I have a PC object that I can ghost around on crashing into randos AND somehow can spring off a scene in a different window on the same character and RP it out while that is still happening?

That's totally doable. I was tinkering with a redshirt thing, but also with the wiki integration fu for a while. Similar to the way a desc for a location can be stored and yanked for a temproom, well. Was originally for NPCs, as a quick means of pulling up their stats, but you could easily enough just yank an instance of your own stats instead of an NPC's, etc. If +finger and its equivalents can be populated from a web form/wiki/web page powered by a database, which is entirely doable as a thing, so can that. It's not really much different than doing it with a room.

Ashen-Shugar

@rook said in Alternative Formats to MU:

You're right, but if we're honestly talking about something to replace telnet, I think that our 'core' needs to be broader than 'every game uses this'. It needs to have a full enough list of features that people go 'that looks better', and that's going to include, IMO, logging and conflict resolution.

Point of order... I am confused by the constant usage of the word 'telnet' in this conversation. Telnet is a protocol, like HTTP or SMTP or SSH. This misunderstanding has clogged a lot of this conversation from a technical perspective.

I think the better term to be using here would be 'server codebase', which is the application like PennMUSH or RhostMUSH or TinyMUX or AresMUSH that people are logging into. That is what provides the features that you are discussing.

Not picking on anyone, but please. Unless you are speaking to the specific carrier protocol that people use to log into the server, don't use the word 'telnet'.

What is being discussed here is design for the server, not the protocol.

Also? Please don't just say "Whatever Rook", because it is important when you are engaging people from a technical perspective. God help us if @Ashen-Shugar sees this.

Whatever Rook.

You deserved that for the Ashen-Shugar comment

For what it's worth, it's again why I made the API in Rhost. Why I'm having people help me in making a completely code-independent API parser into the main engine.

If people don't want to use telnet, don't.
If people don't want to use web interfaces, don't.
If people don't want to log, don't.
If people want to log everything, go for it.

Right now, with the existing Restful(like) API, Rhost allows you to interface, connect, query, and push and pull data from the game, without using telnet. Without logging in a player. Without anything more than an active end-point dbref#. And that dbref# can be any data type. Room, exit, object, it just doesn't care.

You use the a url call (any language that can do a header based url call can use this, any web page, program, command line, graphical application... anything that handles web headers.

Game developers hear you when you ask for options.
Game developers hear you when you ask to be able to enable and disable anything you can think of.
Game developers hear you when you ask for more.

But the funny thing is?

All I hear is the people too busy complaining about how something doesn't work to bother discovering the issue has already been resolved in some of the codebases.

And this is why @Rook didn't want me to see it I guess.

Meh handwaves do whatever. I'm tired.

Thenomain

As a note: Logging every bit of said or posed text takes a fuckton of space over time. Even only logging the OOC room on The Reach ended up taking up enough space that @Chime said "please cull the log", and that was just one room, albeit one room of spam. And this is knowing exactly how much space text takes in UTF-8 (which is my international character set of choice).

There is no design demands in this, it's just something that came to mind, a bit of of the coding flotsam that constantly goes through it.

Alzie

@lotherio said in Alternative Formats to MU:

I mean, honestly, wasn't that the entire point of going from MUD to Mux to MUSH to whatever, more players could softcode while playing inside the box to accommodate whatever system was floating their boat that day?

No.

Mud -> Mush:

Removal of the imposed security settings from the server (Muds actually have a strict role based permission hierarchy built in)
Allow anyone to alter the game by adding objects or rooms (Because of the hierarchy, only people with a specific permission level or higher can alter the game on muds)
You may think the internal scripting language was a reason, but mud's already had that. It was the first two.

Mush -> Mux:

Mux is Mush
The only real differences here are in how the platform reacts to players and how softcode evaluates booleans

@roz said in Alternative Formats to MU:

When I've been using it, I have indeed been speaking about the specific carrier protocol, which is one of the things limiting development.

To preface this, Roz certainly isn't the only one so far to have this sentiment, but Roz is the quote on this page.

Telnet, the protocol, is only as limiting as you make it. The telnet protocol, itself, only governs connecting to a server, sending data between you and this server, then disconnecting. What that data is, how the server responds to it and what rules govern your communication with the server are outside the scope of the telnet protocol. The telnet protocol is a communications protocol that governs a connection and transmission procession with another client.

I think there's a confusion here that if we allow backwards compatibility with telnet it's an all or nothing agreement. This isn't true. You could allow a telnet client to connect and make the same commands people have always been used to, but also provide a web client that runs off a restful API. These things are not mutually exclusive.

Roz

@alzie said in Alternative Formats to MU:

I think there's a confusion here that if we allow backwards compatibility with telnet it's an all or nothing agreement. This isn't true. You could allow a telnet client to connect and make the same commands people have always been used to, but also provide a web client that runs off a restful API. These things are not mutually exclusive.

I mean, Faraday has already talked about how doing backwards compatibility with telnet makes her job harder. I've heard multiple developers talk about how to really do what they want to do, they need to move beyond telnet, and that the restful API isn't actually adequate to their plans and needs.

Arkandel

Mind you, there must be a separation between providing new ways to doing things - that is, allowing for the possibility things could be done in a different way - and figuring out whether that's for the best.

For instance let's take travel from A to B. In traditional MU* that's a very spammy affair, and some people don't learn grids to begin with so they bemoan it; different approaches have been taken to mitigate these issues, from not showing the full room descriptions while you're traveling (i.e. only showing those when you explicitly type "look") to being able to summon/jump to a friend with permission directly. And yes, those could still be improved with a web interface by completely eliminating spam altogether, choosing your destination visually from a minimap overlay or whatever else.

However.

That is necessarily the best way to do things. For instance World of Warcraft specifically moved away from providing instant travel (and still only allows specific static portals, mostly for use between expansions and not cities or landmarks in general) in order to facilitate immersion and the concept of a consistent world by giving players a sense of scale of entire sprawling continents, ruined kingdoms and lush landscapes they'd have otherwise never visited unless they had to.

It still doesn't mean moving to a new paradigm isn't important. As it stands we simply lack the technical capability, due to telnet's inherent limitations, to do many things differently. Other solutions are imposed by those limitations so they might be wild goose chases if we carried them over to a new platform.

Alzie

@arkandel If we're talking about travel specifically, My personal opinion is that no game needs a grid. It's an expected feature of a game, but the reality is that nobody actually RPs in 90% of the rooms most games have. The reality is that you could open a game with a clear theme and maybe 10 important, constantly used locations alongside a coded RP Room creation wing and it would work just as well.

The problem is that if you do this, people will stare at you like you're fucking nuts.

Arkandel

@alzie said in Alternative Formats to MU:

@arkandel If we're talking about travel specifically, My personal opinion is that no game needs a grid. It's an expected feature of a game, but the reality is that nobody actually RPs in 90% of the rooms most games have. The reality is that you could open a game with a clear theme and maybe 10 important, constantly used locations alongside a coded RP Room creation wing and it would work just as well.

The problem is that if you do this, people will stare at you like you're fucking nuts.

Well, yeah, maybe. Probably. I certainly don't like grids - I know other people who do, however.

In this thread's context though all I'm saying is that the key isn't so far to do away with some features we are familiar with or to do them differently, it should be to provide the technical capability to do so.

A transition to a web-based model provides options. Some games will still screw this up but some won't, and over time someone will stumble into cool features that allow these tools to evolve, same as MUSH and MUD codebases did over the years.