Posts made by faraday

@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.

@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.)

@derp said in The Death Of Telnet: Is It Time To Face The Music?:

Either way, there is a non-rocket-science way to do it that could easily be shown on the entry room desc. This just seems like... bloat. I thought we were trying to move away from that on the player side?

Well the way I've done things with Ares is a built-in alias system that's transparent to the user. For example: what I tell new players, what the help files say, etc. will all tell you to read a bulletin board by typing bbs <#>. But bbread is aliased to it for those of us who have been using Myrddin's bbs for 30 years and would have a hard mental time switching to anything else at this point.

So in the same vein... /me will never appear in the help docs, but if someone used to it from other systems tries to use it, it'll just work seamlessly. Given that it's just one line in a configuration file, I don't really consider that 'bloat' personally.

@derp said in The Death Of Telnet: Is It Time To Face The Music?:

@faraday said in The Death Of Telnet: Is It Time To Face The Music?:

I just added this to Ares for you, though it doesn't work in Atlantis because Atlantis sucks up anything that starts with '/' apparently.

How is that substantially different from the \ and \\ we already use?

I never claimed it was a tremendous leap forward or anything. @surreality requested an /me alias for pose (for compatibility with chat programs) so I added one. /me and \ aren't the same command at all, so I don't understand your question.

@thatguythere said in The Death Of Telnet: Is It Time To Face The Music?:

What I don't want is giving some random other player the ability to shit out images on to my screen. I much prefer them getting to put a link I am politely not click on. If the default is to see them and the onus to figure out how not to is on me that is not a situation I would care to sign up for.

Then don't? I mean nobody's forcing you to.

But I'm pretty confident in asserting that the number of people turned off by having to use a command line with an obscure syntax is far, far, far greater than the number of people turned off by having to click a button in their account profile to disable images from automatically appearing.

@thatguythere said in The Death Of Telnet: Is It Time To Face The Music?:

I think a lot of the rancor by myself and others is some of the we must move forward stuff involved a direct repudiation of what we like about the hobby.

If the thing you like about the hobby is having to type +bbpost Board=Subject/Message then yeah, I can't help you. Keep playing Penn/Tiny I guess.

But other than that, I don't see how making it easier to do things people are already trying to do is a repudiation of anyone. Nobody in this thread is talking about radically changing the fundamental style of gameplay. Folks already link to their character profile images from +finger or @desc. They already insert image links into room descs. Don't want to see them? Hey, that's a perfectly fine feature request, which is already common in some chat clients.

@surreality said in The Death Of Telnet: Is It Time To Face The Music?:

@faraday The sad thing is, so much of that can be done in mediawiki... except the chat part.

Eh, kinda but not really either. Maybe if you just want a super-simple lightly-coded one.

@Alzie - You're splitting hairs. I could implement a sophisticated communications protocol over an 8-bit serial bus too if I really wanted to but that would be supremely silly from a technical standpoint. Especially when standard web protocols do everything we need already.

The server-client protocol isn't even the biggest hangup, it's the MUSH clients. Maybe you expect somebody to invent new cross-platform MUSH clients across windows/mac/seventeen-flavors-of-mobile, but I don't. So what you're dubbing technically possible I say is largely impractical.

@alzie said in The Death Of Telnet: Is It Time To Face The Music?:

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.

A short list? I want, in no particular order...

• A GUI, so I don't have to remember/type obscure command-line syntaxes just to do everyday stuff.
• Standard text formatting like bold and italics and links.
• To edit a pose after I've posed it, like you can in any other forum or text chat program.
• Graphics embedded in descs and character profiles.
• An integrated MUSH and wiki so you don't have to update your wiki page when in-game data changes.
• To configure a game without /grabbing attributes in obscure formats off of obscure objects.
• To code in a normal programming language, not line-by-line interpreted commands pasted into a telnet client.
• To play with a decent experience from a web browser, when I'm not at my normal computer. (Which oh-by-the-way also works for new players who haven't downloaded a MU client.)

I could go on, but I'll stop there because isn't that reason enough?

A few of those things you can do crappily over telnet (witness pueblo, which never caught on because it was non-standard and clunky as heck), but most of them you just flat-out can't.

@kanye-qwest said in The limits of IC/OOC responsibility:

I wish I knew how to make people be considerate of each other, and not take everything as a personal slight when there are much more plausible explanations.

Ah yes - totally. That's a separate and equally valid problem than what I was describing. I was referring solely to the 'gatekeeper/roadblock' phenomenon where nothing can get done in a given sphere/department/house/whatever if the leader is shirking.

@kanye-qwest said in The limits of IC/OOC responsibility:

Then the deputies are gatekeepers. The problems people describe with PCs in leadership positions are always going to exist, even with NPC leaders, because those NPCS will not (and probably should not) be around to make all the decisions the playerbase will face.

Not really. If the deputy isn't available, then the staff can have the sheriff do the thing instead. It's a fallback, that's all. It doesn't in any way stop people from RPing with the deputies about crime stuff. Deputies are RP enablers without being gatekeepers.

@surreality said in The Death Of Telnet: Is It Time To Face The Music?:

Set up a /me <pose> alias or command.

I just added this to Ares for you, though it doesn't work in Atlantis because Atlantis sucks up anything that starts with '/' apparently.

@aria said in The Death Of Telnet: Is It Time To Face The Music?:

It was quit literally what I started in.

Not really. I mean you said it yourself - it had far less coded capabilities, email groups instead of boards, licensing fees, proprietary system, etc. That is worlds different than a modern web app with everything you currently have in a MUSH reborn in a free, open-source and extensible codebase.

@arkandel said in The Death Of Telnet: Is It Time To Face The Music?:

That places a higher onus on developers here. Not only do people need to be good with code but they need an extra thick skin to handle all these gripes without wondering too much why they're doing all this extra work for what sometimes seems like an unappreciative community.

Given that the current state of affairs leads potential game-runners to "Step 1: Do you have a coder", I would turn that back and ask why the community really wants to put more onus on the coders. I'm not saying it has to be all rainbows and sunshine, but man... it's really hard to keep swimming upstream against a constant tidal wave of negativity.

@rook said in The Death Of Telnet: Is It Time To Face The Music?:

How would you completely redo MU* so that it is not command>output in two windows? Is that even a goal here?

It's my goal. Here's a rough prototype of how you might do scenes. Bear in mind it's only a prototype and I've already changed some things in the current web portal implementation. I'll no doubt change it more before it's done. The only reason there's still a telnet interface at all is for backwards-compatibility with existing players who don't want to switch, though that adds a lot of complexity to the codebase.

But as @Arkandel says, we can debate it till the cows come home and frankly I'm tired of defending the idea. I'm building it. People will use it or they won't.

@rnmissionrun said in The Death Of Telnet: Is It Time To Face The Music?:

Evennia has been around for 11 years. I would hardly call that 'young'.

People have been putzing around with it for 11 years, yet it's still on a 0.7 beta release and the first real games only seem to have hit in 2016. @Griatch can comment on its status further, but as far as I can tell it's very much still in development.

ETA: Ares, incidentally, is also 11 years old. I started fiddling around with it back in 2006. And it's not done either.

@derp said in The Death Of Telnet: Is It Time To Face The Music?:

"How do you do this in a way that allows for a diverse range of games like this code allows for without just creating every game from the ground up?"

That's exactly what platforms like Ares and Evennia are working on. Evennia is still young. Ares isn't even done yet. I just wish folks (not you specifically) would give them time to try to do the thing before declaring that the thing can't be done.

I agree with part of what @Auspice said: Yes, what sets MUSHing apart from those other games is the style of how we play. IMHO there are two spectrums at work here:

(Online Tabletop) ...... (Collaborative Writing)
(Real Time) .... (Tennis Match For Extremely Patient People)

In terms of style, most MUSHes are closer to online tabletop (sheets, rolls, rules) and hyper real-time. Things like PBP and Storium may have sheets/rules, but ZOMG are they slow. You toss out a pose and wait two weeks for a response. It astonishes me that they manage to hold anyone's attention. MMO RP is real-time, but without the tabletop trappings. It's just emits.

That said, I agree with @Moonman that playing over telnet(*) is driving away people who otherwise might love our style. Ultimately I believe it will be the death of our hobby.

I said it in another thread, but the current generation of adults at least can tolerate MUSHing if motivated enough because they grew up on DOS and things like that. The majority in the next generation has never used a command-line tool in their lives. Expecting the touchscreen/mobile generation to learn "bbpost board=title/message" just to play a game is insanity.

(*) - Since everyone always trots out the "telnet is just a protocol" argument - I'm using it as a shorthand for tools that are limited by our choice of telnet. Command-line-driven, no mouse control, no graphics, no web support, and no basic support (bold text, emojis, editing what you just typed, etc.) that you wound find in every modern text communication app.

@surreality said in The limits of IC/OOC responsibility:

They just have less agency, really, when it comes down to it, since the decision-making power is in the hands of someone they have to track down and ask

Yes. Players seem to be far more willing to beg forgiveness than ask permission when it's a NPC leader. Putting NPCs over them can actually give them more autonomy. This is true even for middle-tier leaders, which @Arkandel mentioned. A squad leader isn't the CO, but they are The Authority for their squad with all the baggage that entails.

I don't want to cry Wrongfun here if games choose to allow PC leaders at whatever tiers they want to. That's their choice, of course. My experience simply has been that the cons far outweigh the pros.

@surreality said in The limits of IC/OOC responsibility:

I honestly think 'gatekeeping' positions IC are bad news for a game, period.

+100 for this. The only reason we're having this discussion about an "appropriate" level of IC/OOC responsibility is because games persist in giving players IC/OOC responsibilities that prevent other players from playing without their permission. This is not at all necessary, and IMHO it's very detrimental to the game.

In a Wild West setting, the sheriff is a gatekeeper. Make them a NPC and let the players be deputies.

In a military setting, the CO is a gatekeeper. Make them a NPC and keep everyone on an even playing field rank-wise. (TGG was the first to do that, and I've done it on BSGU with good results.)

Players in my experience are far more willing to "beg forgiveness rather than ask permission" if they're dealing with a NPC leader rather than a PC one, as long as staff doesn't bash them with a micromanaging hammer.

Yes, it's super dooper amazing when you get a player who's able and willing to be a great IC/OOC leader. But I really think it's time we stopped designing our core game concepts around ideas that only work when you're lucky enough to get a rare unicorn to play them. Then people can just relax and play without worrying about devoting X hours a week to administrivia (IC or OOC). Then this idea of "responsibility" falls away for everyone who's not staff.

(You can't get around the IC relationship issues when people stop playing, but that's a different beast. Unless you're a roster game forcing marriages on people, they chose to be in that situation. They can sort out how to extricate themselves from it.)

@arkandel said in The limits of IC/OOC responsibility:

Yes, and when it's worked well it was exceptional.

Sure, but I asked if anyone had seen it work in general. But the responses so far mirror my experience: It's rare. It's the exception not the rule. When it goes wrong it's a dang train wreck.

We as a hobby spend so much time fussing over activity requirements, tryouts, contingency policies for the inevitable failure... why do we keep torturing ourselves with something that has proven time and time again to fail waaaaaaaaay more often than it ever works? Instead of just embracing the fact that this isn't a very good way to do things and exploring alternatives?

Related but possibly tangential ... Has anybody ever seen IC PC leadership work out well in general? Sure there are those rare non-staff players who can handle both the OOC and IC demands without flaking out or abusing their authority, but does it happen often enough for people to really continue beating their heads against the wall? I gave up long ago. It seems that a lot of these problems go away if you just don't go there.

@arkandel said in The limits of IC/OOC responsibility:

What I'm asking is... are all these cases individual, whether explicitly written rules exist for them or not?

I think they are, truly. Even something as simple as an login-based idle policy invariably leads to exceptions, let alone something as complicated as "are you active enough".

You ask - is it fair for someone to file for divorce because you've been gone for two weeks? I ask: Why not? Is there ever a circumstance where someone should be chained to an IC relationship they OOCly don't want to be in any more?

You ask - is it fair to take away a mastermind position from someone who's not mastermind-y enough? I ask: Why would you? Do you expect everyone to be able to RP their character convincingly? Would you take away a doctor PC if their player couldn't play a doctor to someone's satisfaction? Whose?

We could go through scenarios all day long, and you'll get a variety of answers and justifications from different people on each one.

Playground rules say that its up to those involved to sort it out, and to staff to intervene when they can't. In the end, you just make the best call you can and leave it to other players to decide if you're fair or a tyrant. Ultimately people vote with their feet.

@arkandel said in The limits of IC/OOC responsibility:

'responsibility' players can be expected to sign up on, and what are the limits?

For me, the only people who should have responsibility are the staff. Everyone else is there just to play the game and have fun. Who wants a second job?

Courtesy is more important in player-player interactions. If someone is your employee/SO/sibling, then it's courteous to give them a scene on a reasonably frequent basis to support that relationship. If someone is participating in your plot, then it's courteous to reply to their questions in a timely fashion and not leave them hanging.

If you're not going to be courteous to your fellow players, then you can't really get too bent out of shape if they decide to go seek their fun elsewhere. This is something that I feel is better handled by "playground rules" than by any game policy.