UX: It's time for The Talk

Lithium

@HelloProject That was just an example. Try to auto code Hero Games System, or Anima, or Exalted, etc etc.

There's a lot of things that /can/ be coded, but that doesn't mean it will be helpful.

There is no coded holy grail /unless/ you dumb systems down to the point that it's point and click like an MMO.

Most Table Top systems aren't designed for that. They're designed around modifiers for environment, what you're doing, etc.

If I have to take into account every modifier I'm /still/ going to have to learn a coded command that is going to be counter intuitive in some respect for someone because there's no such thing as a perfect game, or perfect system.

faraday

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

I highly doubt you or anyone else would go "Well, shit, I miss when my syntax had needless complications".

Actually in my experience that is exactly what people say. Because you have people who have been playing this hobby for 20 years who know that syntax and are used to it the way it is. In a world where people avoid playing on MUX or Penn because the channel system is different, this is not an effect you can discount and expect to be successful.

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

For the record, even the +combat commands in FS3 can be simplified. I know because on X-Factor where I used to staff, we aliased simplified versions of them. (Such as adding an "attack" command to alias to +combat/attack and whatnot.)

That comes down to UX style though. Consistency versus simplicity. When everything is +combat/foo it's easier to remember IMHO, as opposed to when some things are +combat/foo and other things are just foo. If having aliases works for you, great. But I would not call it a universal preference.

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

don't make it a complete mess that needs 5 help files to explain how to use something.

You seem to be fixating on the number of help files. If there are a lot of features to document, and you do a good job explaining not only the syntax but when and why to use them, you're going to get more help files. That's not a bad thing.

FS3 Combat is involved. But there are levels to the documentation: an Interactive Intro Tutorial, a Quick Reference Guide, and then the full Documentation for those who really want to dive into the details.

It's the quality of documentation and the ease of use that matters, not the number of pages. (Btw, I'm sure the documentation can be improved. Just using it as an example.)

As @Ganymede and @Seraphim73 have mentioned, with Ares I've made a concerted effort toward UX while preserving the user experience of Penn/MUX as much as practical. People generally seem to be pleased, but there's always room for improvement. The help files for AresMUSH are all online. You can find them here. Pick a system. Tell me how to make it simpler without sacrificing functionality. (Of course if you ditch features you can simplify the syntax.)

Doesn't need to be (and probably shouldn't be) done in this thread, but I'm completely serious. I'm open to feedback here. Good UX on a MUSH is not some rainbow unicorn.

SparklesTheClown

@faraday I don't think I've actually seen/heard of AresMUSH yet, haven't checked the ads in a bit. But I'd certainly be interested in looking at it some time.

That said, my intent wasn't to say that all games and all coders are doing horribly in this area, and I am glad that a lot of people are open to simplifying things.

This thread is certainly educational to me for a number of reasons though, as I'm getting to see the general perspective of why certain design decisions are made.

WTFE

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

As somebody who knows 0 about code, I assume MUSH code is archaic and sort of hack-jobbed, since it varies wildly from game to game, and outside of the copy/paste WoD games or FS3 games, etc, MUs flat out have 'custom code' that somebody just made in their free time.

MUSHcode is a Lisp written by someone who took a Lisp course and didn't really understand it. (He probably got a C+ in his course.) It's a functional language in which user-supplied functions are second-class citizens. (What do I mean by this? Using the results of a built-in function in look like [function(parameter1, parameter2)] where user-supplied functions have to be stored on some object somewhere like this &SOME_POINTLESS_NAME object=FUNCTION CODE GOES HERE and is called like this (using its results): [u(object/SOME_POINTLESS_NAME, parameter1, parameter2)]. What's that? You want lambdas? Closures? BWAAAAAAAAAAAAAAAAHAHAHAHAHAHAHA! He'd have had to have understood those from his Lisp course to have thought of implementing them!

And that's only the lowest level of the problems with the language. The larger scale issues are that MUSHcode resists modularization, so it's actually hard to make shareable code that someone who isn't steeped in the language can use in a "plug and play" fashion. Some attempts have been made at this--heroic attempts whose champions are honoured as they reside in Happy Dale Sanitorium charging up staircases and blowing trumpets--but they really don't work well because out of the box they're pretty vanilla and bland, and customizing them requires, you guessed it, someone steeped in the language. (And because of that resisting modularization thing, using code from more than one source starts exponentially increasing the risk of brought-in code clashing in unexpected and surprising ways.)

Factor into this the added problems that there are three major dialects of the language (Penn, MUX, Rhost) with incompatibilities both subtle and grotesque, that the language was built on a today-bizarre foundation of queued resource management, that the servers all have weird limitations (often based on that queuing system) in unexpected places that requires baffling code to work around, and that until recently code was jealously guarded instead of shared (Rhost once had an NDA you had to sign if you wanted to use it!) and you have a perfect storm of ... well, random hackery and "NIH"-based clusterfucks.

Not to insult anybody or anything, but I'm going to go out on a limb and just say MUD coders are probably better coders, or at least have way more time to code.

Nah. MUD coders just have more access to better tooling for their code bases beginning with the fact that most MUDs are coded in languages for which there are a myriad of resources for learning and a myriad of ways of finding code (that won't break existing code!) to bring in for reuse.

Personally, I find culture variances between muds/MUSHes pretty curious. Little things like how a huge chunk of the MUSH population can't be fucking assed to read the bboard even once a week, where MUDs have forums/etc dedicated to the game and people are commenting about things on the game hourly, nevermind in-game noteboards that get checked p.much every time you log in.

See, that, to me, is one of the turn-offs of MUDding: if you want to play a MUD you pretty much have to dedicate your life to the fucker or get left behind. (By which I mean "killed" of course.)

Well, that and the endless grinding that MUDs seemed to always demand. There was a MUD I tried that advertised itself as "RPI" and bragged about how it was SO ROLE-PLAYING-ONLY! And it was. Even the in-game help was mostly IC. When I made my character I had to interact IC with one of the "helper staff" types (actual IC counsellor positions!) who did a commendable job of guiding me through how to get into the game. Only one problem: here was a typical segment of that help session:

Helper (H): So what kinds of things did you have in mind for your future in our city?
Me (M): Well, I was thinking of learning to be some kind of healer or maybe an apothecary.
H: Commendable choices! Laudable, really!
H (OOC): We really do need more healers. You should get to the sewers and kill rats.
M: (OOC): What?
H (OOC): To get enough experience that you can train as a healer.
M (OOC): <hangs up>

OK, I wasn't quite that abrupt, but that was a serious "wut" followed by a "LOL" moment for me. In this game that prided itself on how IC everything was, beginning characters, each man, woman, or child of them, had to basically start off by going to the sewers to kill automated rats to get experience and money so that they could do the things they ICly (and OOCly, obviously) actually wanted to do.

And that was one of the better MUDs I tried. Bad ones like that Sciorsiecieasceaisareas one (that actually wanted money at one point!) made you micromanage eating. If you didn't make enough money (by grinding, natch!) to buy food or, alternatively, hunt (by grinding, natch!) enough food you died. Travel times were enforced, so if you had to go somewhere to do the grinding you needed to do to live, you could (and I did) die along the way trying to get the food. And this was lauded as "true role-playing" by its advocates when I did the "WTF!?" thing on channels.

So, you know, all that culture shock you had at MUSHes? Guess what happens a lot when people go the other way...

SparklesTheClown

@WTFE Oh, I've 100% been on MUDs like that. Especially with eating and drinking code.

Eat/drink code is the bane of my existence and I pretty much started to leave a place as soon as I realized they had it, because "YOU ARE HUNGRY", "YOU ARE STARVING" prompts got annoying as shit, especially on places where you don't even die and it's just there for no reason.

But you likely do have a point with the resources. I guess this is why Evennia exists now. I'm making my game with Evennia.

WTFE

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

But you likely do have a point with the resources. I guess this is why Evennia exists now. I'm making my game with Evennia.

I really, really, really had high hopes for Evennia, but I found it had a couple of crippling problems:

The process for installing it is idiotic. I eventually got an installation sort of running. I think. (I'm not sure if it was properly and completely installed because by the time I finally reached that stage of being able to log in I'd lost all interest in using it.) Even old-school code bases like PennMUSH or Rhost were easier to install!
The documentation reads like the documentation at Oracle's site for Java SE. It's filled to the brim with over-engineering and turgid prose that I keep handy on my bedside table for those sleepless nights.

Now for the scale of that installation and documentation problem: I currently code embedded systems for a living. One of the smaller MCUs that I use has over 1200 pages of documentation that was written by engineers. ITALIAN engineers. Who painfully obviously have a few issues with writing in English. In total the chips I use from this company have documentation that exceeds 3000 pages. And that's just the MCUs. Each peripheral device I use has manuals that range anywhere from 20 pages in length to 900. (Many of the "peripherals" are MCUs in their own right that just have permanently-burned firmware.)

Further, for my home usage (not work), I use F/OSS tools instead of commercial ones. Documentation for F/OSS tooling is notoriously terrible and the tools rarely, if ever, are designed to actually work together coherently. My compiler is GCC and my assembler is GAS. (These two work well together, and they both work fine with GNU's link editor.) My debugger is GDB and I use OpenOCD as a bridge between GDB and my chips' debug modules so I can actually flash and debug my code. As an added "fuck you", GDB is scripted in Python while OpenOCD is scripted in Tcl (and the link editor has its own fucked-up scripting format for moving things around).

Just the infrastructure coding in any given project--the code that exists solely to bind together the various tools I have to use in something resembling coherent whole--is typically several hundred to thousand lines of Rexx scripts I cook up for each project (though, to be fair, most of it is cribbed from other projects and I push a lot of common code into a cookbook library).

It's a total fucking mess. And I find it easier than installing Evennia was.

Rook

God, @WTFE, I can't agree more, and I want to love it.

Ganymede

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

I don't really understand how I'm coming at it from a position of relative privilege. Considering that for most of my MUing life, I've been a non-coder, which is why it never occurred to me that things could be better.

If you've spent most of your MU existence as a non-coder, then you've had the privilege of enjoying the fruits of others' labor. That's what I mean by "position of relative privilege." My understanding from the coders I have personally known is that coding takes considerable time and effort. That is, they have invested a lot of time and effort into how they've designed, modified, and produced their code.

While my hyperbole might have been a bit extreme, I legitimately don't think that a lot of coders are in a position to think about something like UX anymore than the non-coder creator of the game generally knows what's going on with the code.

You may legitimately think this, but you're also legitimately presuming it. Hiring someone to advise on user experience for a video game that has a budget and is produced for mass consumption is very different than what the average coder does for a MUSH, where they aren't paid and rarely recognized for their efforts. When you're done coding your game, I'm nearly positive you will experience that usual shitting-on that I've heard many coders receive and complain about.

That said, I've been atop of games before, and I try to talk to my coders about what they want to do and if they can improve on things. Sometimes they can, sometimes they can't. It has been said before, but a good game takes time to develop for this very reason. And the coders I know get really fussy when you push them to do something that their carefully-developed code won't handle without a massive overhaul.

I start discussions because I know that, regardless of my decade+ in the hobby, I'm still relatively new. And being relatively new, I think that it's important for me to occasionally bring up things that I've noticed or that I see as problems.

Again, this is not a new problem you're raising. But I've never seen someone describe the current state of any MUSH code as "monstrously shitty," especially when they are actually trying to start an open dialogue on improving code.

I want to contribute to the community, and I admittedly am still trying to improve at how I present myself and my arguments, when to be professional and when to be casual, but I 100% am just trying to help anyone who finds what I say or discuss helpful.

Fair enough. Let me suggest this, then: when you're dealing with a sub-group of the hobby who regularly takes crap and gets crap about their work, it's better to open with "let's work together in trying to pare down some of the redundant, old-fashioned, out-moded code we toss onto game" than with "the current state of affairs is bullshit and you ignorant fucks should have done shit to improve it by now."

People are trying to improve things. Honestly. So, my recommendation: minimize the hyperbole, ask questions, scout around, and take inspiration where you can find it.

SparklesTheClown

@Ganymede

I don't necessarily disagree with these points, so I'll keep it all in mind.

@WTFE

While I don't doubt that this is likely true, once I do manage to get it setup, I think I'll benefit a lot from using Evennia and learning Python rather than doing MUSHCode. Primarily because a part of my motivation for this project is to dive super deep into code as a sort of trial by fire, since my plan is to do it professionally and building this MU is incredibly motivating.

If nothing else, I figure Volund will help me parse the documentation if I don't understand it, since Volund has been trying to get me to do Evennia stuff for a few years.

WTFE

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

I think I'll benefit a lot from using Evennia and learning Python rather than doing MUSHCode.

I think this is likely accurate. I can't think of any non-MUSHing advantage to learning MUSHcode. Further, learning MUSHcode is a non-trivial venture that's fraught with frustration and WTFery with very little useful support provided compared to the reams of books and blogs and videos forums and user groups and ... that you can get for Python.

In the modern era of MUSH servers you can, to varying degrees, get to use Python (or other scripting languages) through hacky external language interfaces, but these are slapdash compared to writing natively. MUSHcode is pretty much its own ghetto in this regard.

Groth

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.

Derp

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

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.

This. @HelloProject, you keep talking about 'things could be simpler', but honestly? I don't even know what that means in this context. I keep seeing in my head this idea that you want to just type in, "Computer, add a knife to my inventory, give it a +2 damage rating, make it one size level bigger because I'm a giant, and set a note on it that it was a gift from my girlfrirend'. MU doesn't come equipped with Siri, nor is its engine star-trek-esque.

Code creates commands that are either complex or numerous. There is no in between. If you have a system that needs to do five things (not necessarily at the same time), then you end up with either five commands, or one command that can do between 1 and 5 things depending on its syntax, which makes it complicated. (And either way, those five things require documentation).

Nor can you easily have one command that does more than one thing (unless, as above, it has a complex syntax). A command with a simple syntax will do precisely one thing. A MU will not understand the difference between 'add knife' for an inventory command or 'add boobs' for a desc command unless you literally tell it where every possible word would apply, or make it different for every room its used in.

So what exactly are you looking for when you say 'things could be simpler'? Because at the end of the day, I tend to go with "It really can't be."

Edit: Corrected some pre-coffee grammar booboos.

Rook

@Derp
+1 because you said booboos in a coding discussion. Well done!

faraday

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

So what exactly are you looking for when you say 'things could be simpler'? Because at the end of the day, I tend to go with "It really can't be."

A few concrete things that I've done with Ares, just to further the discussion:

Sensible Command Names - Why is the OOC profile command named +finger? Or the build command 'dig'? Or the private chat command 'page'?
Consistency - The mixed up mash of coded systems on most MUs often leads to bizarre inconsistencies - like one command uses subject=message and another uses subject/message.
Redundancy - +help versus help or +desc versus @desc anyone? MU systems overlay on the base hardcode implementation, so you end up with multiple ways to do similar things. Which is sort of related to...
Command Prefixes - Why is it @desc versus +where versus quit?

Now I personally know that a lot of this stuff has historical roots. +finger from the unix command, @/+ prefixes for softcode vs hardcode. But when you look at it as an outsider it's un-intuitive, needlessly complex, and just plain goofy.

Ares is an attempt to make these things better while still preserving backwards compatibility for the syntax people were used to.

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

If you have a system that needs to do five things (not necessarily at the same time), then you end up with either five commands, or one command that can do between 1 and 5 things depending on its syntax, which makes it complicated. (And either way, those five things require documentation).

Yeah there I agree with you completely. I'm not convinced that remembering 5 commands is easier than 1. But I do agree with @HelloProject that you can make at least the basic versions simple. For example, in Ares the basic attack command is just combat/attack Bob and the basic roll command is just roll Alertness. But both of those commands have more advanced options that you can provide only if you need to.

Rook

I have no idea who started the whole +-prefix shenanigans, and I know @Ashen-Shugar and I have had long bitch-rants about some things like this, too. There is nothing saying that the softcode has to start with +, anywhere. Why people do it? Convention.

The commands without the @ symbol were intended, I believe, to be non-logged-in commands, so that you can run those from the Connect screen. WHO, QUIT, VERSION, INFO, etc.

faraday

@Rook There are other commands without prefixes that don't work on the login screen, like page, follow, move, etc. I heard once that @ was for commands that alter the database, but that "rule" isn't consistent either (@emit).

'+' came about because you needed a way to distinguish softcode from hardcode commands. If the hardcoded describe command was "@desc" and you needed to make a softcoded one... what were you supposed to call it? You needed a new prefix. '+' is arbitrary, but if you weren't going to muck with the hardcode, it had to be something.

Rook

I believe that those are holdouts/leftovers from TinyMUD, which is where MUSH derivatives come from (mostly). @Ashen-Shugar could speak to this much more succinctly.

I'm agreeing with you. I, once, spent a week going through the help.txt file, cleaning up inconsistent formatting, fixing typos, and adding some stuff that I thought should be in there. There is a lot of gap, if you go looking. But now? Softcode is written, egads, tons of it. While you could add aliases to the commands to clean things up, without a fresh install and coding your own... you'd run into issues.

Legacy code stacked on legacy code. Hack after hack. Until a complete rewrite happens, the codebases will have these inconsistencies.

Then of course everyone will bitch that shit got moved/updated on them and their stuff doesn't work.

faraday

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

Legacy code stacked on legacy code. Hack after hack. Until a complete rewrite happens, the codebases will have these inconsistencies. Then of course everyone will bitch that shit got moved/updated on them and their stuff doesn't work.

Oh I agree. That's why Ares is a complete rewrite. We can't go back and undo 20+ years worth of code drift, but we can learn from it. Platforms like Evennia and Ares provide an opportunity to do better the next time around. The question is: What does "better" look like, in way that won't have everyone up in arms because ZOMG it's different.

Rook

Now I am very interested in looking at the codebase. Academically, I'd want to discuss your design document, your coding standards, that sort of thing. Establish rules for everything from command structure to help files. But that's a big undertaking, believe me. I've worked with the Rhost team for years, and while I throw all kinds of shit at @Ashen-Shugar as ideas, and most of them get implemented in one way or another, it is no easy task. I watch that dev team hammer through issues both legacy and limitation-related, and I know it's frustrating.

What can seem like a "small thing" to a softcoder can turn out to be spaghetti-code-diving for the hardcoders to fix the issue causing the gap in the first place. This is why I stick with Rhost, because I've watched that team do rewrites of major chunks of code to make it more secure, faster, better and more featureful.

Rook

Back to the OP's conversation, as slanted as it might have come off...

Lots of games do small tweaks to things to make stuff look homogenous, as they can. But most games don't know how to dig into big systems like Myrrdin's BBoards, the +Jobs systems, and so forth, to truly rewrite interfaces. Myrrdin's BBoards have been around since before the turn of the fucking century, and (yes this is a peeve of mine) haven't changed in that time. They're great for what they do, don't get me wrong, but come on.

Most games still use SGP and repository packages that are drop-in, tweak and forget... and that is the extent of "coding" on their game. Many games just then do without other functionality because they cannot find (or trust, a whole other conversation) a coder who can create that system in the way that they want it, in the timeframe that they want it.

So game owners settle for what is quick to install, configure and get rolling... because honestly, people just want to RP. Which brings me to my last point: Most people don't care about the code. Believe me. I've spent months building systems that people look at and say "Meh, I'll stick with <old system X>". Why? Laziness/Familiarity - two words describing the same lack of motivation to learn something new.

Go ahead and rewrite systems for your upcoming game, and you'll see firsthand what people are telling you here. Not trying to discourage you, it is a very solid way to deepen your coding skills... but don't do it if you are after praise and recognition. Coding is not for you if that is your goal.

People respond much more lovingly to STs and Sphere Wizzen who directly enhance their RP .... far more than they do to coders that provide the system crunchies to get the business of RP support done.