Posts made by Groth

@Ashen-Shugar said in UX: It's time for The Talk:

It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.

Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?

The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.

It's really easy to set things up to send data to and from the mush to an outside application. However if we're going to change the mush protocol and require new clients to be written, why do we even stay with telnet? If we switched from telnet to http/json we could have smart clients who are given information as data rather then raw text. It would know what represents the exits, what represents the players, what represents a pose and what's a command echo etc.

@Lithium

I disagree with the idea that CLI is necessary. If I were to make a text RPG interface from scratch I'd make it web/json based with a rich text editor, graphical map, form based chargen etc

Just like roll20 you might still have some cli commands for advanced features but most players shouldn't need them often

@faraday said in UX: It's time for The Talk:

@Groth Yes, so by all means let's do nothing at all to make things as good as they can be given the limitations of the technology. I've said my peace. I'm out.

TinyMush and derivatives are just about as good they can be given their design constraints, technology and the willingness of people to get involved with the code.

However that technology is from the 1980's and 1990's. If you actually care about an improved user experience for those interested in text based RPGs, I think you really should focus on actually creating something that isn't reliant on a steaming pile of shit rather then bitching about the placement of the sesame seeds within that steaming pile of shit.

@faraday said in UX: It's time for The Talk:

@Lithium I didn't say documentation was evil or unnecessary. But I would challenge you to find a UX book on the planet that tells you to fix UX problems with documentation. (And I've read a lot of them.) Your #1 goal with software is to make it as intuitive as possible so the documentation is unnecessary. When was the last time you cracked open the manual for a PC or web app?

The UX issue with MUSH starts right at step 1) when you're asked to install this really quirky client designed in the 1990's that doesn't even have proper window managers. Then at step 2) You're expected to handle everything through pure CLI and now any hope of being intuitive has been thrown right out the window.

@faraday said in Separating UX from Functionality (Design Patterns!):

@Sparks In principle I agree that that's the "correct" way to do it. I didn't go that route personally for Ares because I have no intention of supporting both a web UI and an in-game UI for most stuff. Chargen is a notable exception. The complexity of supporting two independent views and making sure everything melds together is just... no.

Eh. As long as you follow a good MVC oriented design paradigm (such as the one Evennia is built upon with Django) you should have a pretty easy time supporting any number of different views.

@faraday said in UX: It's time for The Talk:

Those are valid reasons for expanding the functionality of the 'who' command, not for having two obscurely different versions of it. But that's just IMHO. If you're happy with the status quo, then there's no reason to change anything. Some of us aren't, though.

I don't think any MUSH coder will argue that MUSH is an awesome platform however when you critique MUSH syntax and UX, I think it's important to remember what MUSH is actually designed to do otherwise you'll look a bit like someone complaining about a multi-tool being a poor hammer.

Yes if what you want to do is hammer nails, then the multi-tool isn't the best, or even a good choice. However that was also not what the multi-tool was designed to do.

MUSH is standard and a toolbox designed around allowing allowing the users to code almost anything from within the game itself. It's very convenient for most TTRPG to MU* translation games since it comes out of the box with everything you need to make a grid and roleplay, leaving most games to only need to install AnomalyJobs and a roller and they're good to go.

Being a standard is also convenient, because it means that regardless if you play Bob Mush or Alice Mush or Eve MUSH, you know the basic commands used to play the game all work the same way.

I really honestly fail to see how breaking that standard makes things more intuitive and once you do leave that standard, you may as well leave the entire way to Evennia or Ares or whatever floats your boat because I see absolutely no reason to use the Pennmush or TinyMux codebases if you plan to replace their core commands. Any talk of doing such things within the context of MUSHcode is to me insanity.

@faraday
Consider this. Why are people using the MUSH codebases at all? Why don't they just roll their own MUD code like people did before the MUSH codebases were around? Why do people advertise their game as a PennMUSH or TinyMux game rather then Bobs RPG?

@faraday said in UX: It's time for The Talk:

@Groth said in UX: It's time for The Talk:

So how do you now distinguish between the default mail which people expect to be there from your super special mail you wrote for this game in particular?

You don't need to. Really, you don't. If you want to provide good UX for your players, then you will make the basic mail commands on your super-special custom mail program work the same as the basic mail. Then it doesn't matter what additional features you provide.

As long as 'who' tells them who's online, they really don't care what it looks like. There's no reason to separate WHO or +who (other than the aforementioned historical reasons).

One reason to keep the default WHO is that it allows the MU* scrapers to parse your player statistics if you care about being scraped, the default WHO also provides additional information to wizards and gods that most people don't bother replicating into the +who (since WHO does it).

@WTFE
So in this analogy, the @commands and the default commands like WHO etc, are your windows explorer, internet explorer, notepad, windows volume control etc. Only that in MUSH their names are even more generic. If you tried to start notepad but instead got microsoft word, most people would get rather surprised.

While your + commands are your acrobat reader, photoshop etc. Only just like the default commands have very generic names, it's likely you want your taxi command to be named 'taxi' because that's vastly more convenient for the user to type out then 'Bobs Taxi 4.0'. You could always do this the Unix way and give your programs short and cutesy names like 'vim' and 'emacs' but how intuitive is that exactly?

So how do you now distinguish between the default mail which people expect to be there from your super special mail you wrote for this game in particular?

@faraday said in UX: It's time for The Talk:

Can you address this with "getting started" rooms and tutorials and stuff? Sure. But wouldn't it be so much more intuitive if you didn't need any of that? If there was just one and only one "who" command or "help" command, and if you wanted to extend/override it for your own game you could? I think it would be.

Do you actually want the help to contain both all the code documentation (which is irrelevant to 99% of players) and all the game documentation (which tends to be what players are interested in)? In the context of MUSH, that is a common game engine that can handle any kind of game, you really do want the distinction between global commands that work on all games and local commands which will only work on the game you're on.

We certainly could remove the distinction, we can override the default commands. But if we do that then anyone coming from any other MUSH will be utterly lost.

@Rook said in UX: It's time for The Talk:

That's a miss on the coder's part. The room, when dropped into combat, should have had an @oleave/@otport set and the player should have had an @omove set to leave the combat.

Would that even have helped? I could see like half a dozen ways a player object could end up outside the combat room without triggering any of those triggers. The MUSH engine is just not built to handle states, any attempt to make it run a state based combat engine is likely to end up in a clusterfuck.

@WTFE said in UX: It's time for The Talk:

The @ vs. + vs. . vs bare thing never had an excuse except POSSIBLY the hardcode vs. softcode divide if there's no way to override hardcode commands in softcode. But ... a few questions even if that hardcode/softcode divide needs to be kept:

1. Why prefixes at all? Why is it so necessary to TELL people that they're using soft-coded commands instead of hard-coded? Is it really so necessary to have +finger instead of finger? What does the "+" add there at all?
2. I can see, if I squint right, how @desc me=foo makes sense to distinguish a property from a command, but why is it @ for some and & for others? Pick one and stick with it, dammit! Or even better just make setting a command! set <property> <target> <foo>. And to read it get <source> <property> and to read it in code get(<source>, <property>) and so on.

There doesn't exist any command which uses & as a prefix. The & is a shortcut to the @set command(which does exist, so does @get). It is possible to override most of the hardcoded commands but it's inadvisable, being consistent about the +prefix makes things relatively intuitive.

As others have already brought up. the MUSH syntax isn't complicated just because MUSH coders hate players. It's complicated because your average MUSH is actually a bunch of nested systems written in a programming language that was designed in order to be storable as a single string while the core commands are all hardcoded.

All sorts of things like functional timers, interrupts, having more then 20 variables or having variables which are not strings just don't exist in MUSHCode.

Sidenote: @WTFE strictly speaking and syntaxical sugar aside. Mushcode has the same lamba support as any other string based scripting language as it can pass along arbitrary strings and call eval()

Further as @Lithium went into, most of the systems that people play on MU* were never designed to be implemented in coded text form. World of Warcrafts combat system may be 100x more complicated then D&D but it's still going to be a metric fuckton easier to code into a decent game because it's actually designed around the idea of being a computer game. It's the same reason that Hearthstone is a run-away success while Magic The Gathering Online has been a failure since forever, MTG is just a really clunky game on a computer and so are most of our RPGs.

@Tinuviel said in PC antagonism done right:

@Bobotron The massive staff overhead suffered by RfK was due, in perhaps small but not inconsiderable part, to the behaviour of the headwiz. Without her it would have taken a fair slug of work, certainly, but at least they'd be able to get the work done without her going over everything to ensure it fit "her vision."

No, the staff overhead suffered by RfK was almost entirely caused by the fact it was originally conceived as a game run by the book as much as possible, including the LARP rules. However as the game grew more popular it became increasingly obvious that those rules scaled poorly and were not a great fit for a MU* environment meaning that a complete redesign was necessary designed for the MU* context from the ground up, however this is difficult to do when you're buried under the work of actually running the game.

@WTFE said in Comic book diversity:

@Bobotron said in Comic book diversity:

Comics are also getting harder and harder to follow nowadays, I feel like. Comic A references LImited Book H, comic crossover B requires you to know (and care) about all of these other characters (like X-Men vs. Inhumans, I could give two shits about the Inhumans personally, but for me to know X-Men I have to read it).

This. This right here. In my short-lived comics collector phase (about five years total) I was getting tired of this game in the fucking nineteen-eighties! From what I gather observing from afar, between reboots and tie-ins and overarching "Secret Wars"-style plots and consolidations and and and and I just won't even bother sticking a toe into that pool any longer.

Were I going to look at comics at all, I'd look at creator-owned limited runs or their ilk, not anything from Marvel or DC who've made such a total fucking mess of things I'm genuinely not interested in their fare any longer.

Even if it is more "diverse".

The only comic I buy with any regularity is the Donald Duck pocket. This is because.

1. They're the perfect length to read during a train trip or while you're in the bathroom.
2. They have little to no continuity. It doesn't matter in which order you read the stories because with few exceptions they're independent of eachother so when I buy a new one, I never have to worry about the fact I didn't buy or read the 3 previous ones.

I also find the Marvel/DC model to be the weirdest, because you can contrast with the Japanese comics where each comic only has one author, one continuity and little to no crossovers. That means that if someone is curious about One Piece, Bleach or Naturo, you can just direct them to issue #1 and they can go from there without worrying they'll miss anything. What they do instead is just recycle the character archetypes and tropes to such an extent that stock phrases are used to indicate which character is which archetype.

I find this vastly more approachable then the 12 different authors are writing the same character in 6 different dimensions kind of nonsense DC/Marvel has going on.

@WTFE said in RL Anger:

Apparently Gen X/Boomers don't realize that unless they're still using that rotary phone they inherited from their parents, their phone probably is a computer. It's a common misconception among people age 35 and older that if the operating system was released after Windows 98, or there is no CRT monitor, that it doesn't qualify as a "computer."

It's so cute to watch the "techie" call his phone A computer…

Making up your own definition of a word and trying to make fun of other people for not using the word in the fashion you just made up isn't particularly funny or clever.

@Griatch said in What is out there? Hard and soft codebases of choice.:

@WTFE

An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?

As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!

OP: sorry for what may be a bit of a derailment of the thread...
.
Griatch

My main issue when I tried out Evennia is that it felt a lot easier to just ignore most of the Evennia abstraction layers and use Django directly because the Evennia storage obfuscates the data relationships.

@Derp said in House Rules vs Rules as Written:

House Rules need to be written, IMO, like court opinions. You need to both announce the change to the rules, and explain the reasoning for it (which is an excellent use for MU Talk Pages). You need to offer some background to explain why this fixes a problem, so that (in the event someone has an idea that actually does it better) you can scrap the thing. Or, if it turns out you were just being needlessly reactionary after people review it, you can remove it and go back to basics.

You could, but I don't think I would put the background work on the rule on the rules page as that would make what is on many games an already difficult thing to keep up with even harder for most people to grasp in their entirety but if anyone is interested, you should definitely be able to show them.

I think the amount of house rules a game needs depends heavily on what kind of game it is. Back when I played Exalted 2nd Edition on javachats, the list of house rules tended to be absolutely gigantic because that game was near unplayable as the rules were written.

That can be contrasted with Requiem for Kingsmouth which also had an absolutely massive amount of house rules, however RfK's house rules were for the most part additional systems added to VTR2 rather then an attempt to fix anything written in the book.

Generally I rather dislike house rules that change book mechanics since that requires players to look in two places to find out how something works and that also goes for Errata. The absolute worst situation is when understanding a single mechanic requires looking in 3 or 4 places because it relies on two books, official errata to those books and the house rules.

@Warma-Sheen said in House Rules vs Rules as Written:

And does anyone really believe these people who are contributing writing to WoD books have never considered that gamers aren't going to play splats against each other? Or that there won't be players using these systems against other players? How is it we play these games over and over again, and yet people seem to give the writers so little credit for developing these games we love so much. So little.

Let's be honest here. Has White Wolf or Onyx Path ever been known to release tested and solid game mechanics*? I don't know about you, but the reason I play their games is because I love the feel of the settings and you can go a long way without actually throwing dice around.

*VTR 2 was pretty good though.

@Miss-Demeanor said in Social Conflict via Stats:

@ThatGuyThere Ask staff on TR, or even Reno 2.0 if they have the time to come mediate every social interaction where one side doesn't like what the other side is doing. Go ahead, I'll wait.

I don't think I've ever seen Staff get asked to mediate a social conflict as it happened. The way it goes down in my experience is that the scene breaks down, everyone goes home and later Staff gets to find a unique complaint from each participant when they log in to check their job queue.

@Ganymede said in Social Conflict via Stats:

I wouldn't feel the need to continue this, but any policy that would deny the players the right to adjudicate their own conflicts without staff intervention is a horrid policy.

In a non-consent PvP game I'd call it a necessary policy as it becomes the responsibility of staff to ensure a level playing field. In a consent cooperative game, I wouldn't care. When you let people opt out of having to use the social mechanics you create incentive to ignore the social mechanics in favour of the mechanics which are enforced ultimately leading to characters who literally have a chance die on persuasion having a reputation for being charming.

@Lisse24 said in Social Conflict via Stats:

Then design a system that caters to what you think players want. What I don't get about this discussion are the people arguing that because not everyone will be happy with a social combat system then no one should ever attempt to make one. Look, you may not want social combat in your game, but I would actually love to play a game that had that as an aspect and based on this thread, other people would like to try out a game with that, too. If other people don't want to play on a game with social combat then they can stick to games that don't implement that as a system, but why does this have to be an all or nothing proposition?

What I've seen work best in practice so far is incentive based social combat where based on the roll of the attacker, the defender get some proportionate bonus for playing along which can include temporary buffs or xp.

The obvious problem of this approach is that it still leaves you with no way to model long-term persuasion and quite a lot of people will happily dump their social stats and just write purple prose instead which they're practically never called out on.