UX: It's time for The Talk
-
@Paris said in UX: It's time for The Talk:
@Rook A lot of F&L's mushers are completely new to MUX, though many of them are MUDders. We try to help folks get over the learning curve, and have been really happy with what they bring to the game-- several have gone on to staff and it's been great.
Yeah, I spoke to Wildfire when he was STing a thing for me. His style was so different I was confused for a moment, then he explained that this was actually his first MU. It's interesting what new players can add to the hobby.
Though, compared to most people here, I'm still pretty new to the hobby myself, it's just that I spent a ridiculous amount of the last decade doing very little but this hobby.
-
@HelloProject said in UX: It's time for The Talk:
I thought you said you're ready for the flames?
Look you said this:
For years, since I even got into this hobby, I've noticed just really monstrously shitty design practices. One of the most grave shitty design practices is just what I can only describe as a complete disregard for UX design.
Has it ever occurred to you that there are people that work diligently and carefully on their games, and you just went and said, from a position of relative privilege, that what they've done is "monstrously shitty"? And then you conclude that this is a "complete disregard" for user experience? This is neither constructive nor civil.
I don't think you'll get much opposition here to the premise that certain things could be coded better, differently, or more efficiently. Certainly, I'm not going to argue here to the contrary.
When I say "leave the coders alone," I mean "focus on how you can make a better gaming experience for yourself and everyone around you." Blaming the code is easy: what's harder is actually writing up the help files, assisting players in using the commands, etc. So, when it comes to "improving user experience," I think: do what you can do where you can, player or staffer or coder. If you can code things better, great. If not, then still do what you can.
Flip the situation around. I'll bet coders roll their eyes until they spill out when people can't figure out what they consider to be relatively easy code to work with. And maybe it is, and maybe it isn't. I've found in my years that when people are new, other players come to their aid, and new players that invest themselves a little into learning the systems and the ways tend to stick around and meaningfully add to the experience. Once they've done that, like @Paris, they tend to gravitate towards the familiar because of that investment.
So, from my non-coder experience, I would say: maybe if we all just tried a little harder to learn, things would be better as a whole.
“It is better to live doing the things that you like. It is foolish to live within this dream of a world seeing unpleasantness and doing only things that you do not like.” -- Yamamoto Tsunetomo.
-
@Paris said in UX: It's time for The Talk:
@Rook A lot of F&L's mushers are completely new to MUX, though many of them are MUDders. We try to help folks get over the learning curve, and have been really happy with what they bring to the game-- several have gone on to staff and it's been great.
But then again, @Paris, you've demonstrated in a few ways that your game is not like other games. So I haven't, myself, lumped you into that same-ole-same-ole pile.
@HelloProject
MUSH and MUX were both written by coders, it is true. C/C++ coders who wanted to create games, and make them better. I daresay, gasp that so did TinyMUD, AberMUD, Diku and all the other flavors. Writers didn't sit down and suddenly come up with a game.A huge portion of the MUSH and MUX help files are code commands. That is why +HELP exists, traditionally, on these games. Most players barely read the help for @mail, ANSI and Channels. Past that, they are baffled by the help files.
Any conversation around here will tell you that coders are rare, when compared to number of Game Owners, Storytellers, Sphere Wizzen, and the like (simplified: non-coders). In a lot of cases, coders are told by Game Owners what they want, how they want it, and that is what coders are expected to deliver.
When it comes to my code, I simplify as much as possible, not just the commands and help files, but the code itself so that bug-hunting can be done relatively easily by a new coder. My code files are heavily commented with logic explanations, function call help and so on, so if I get hit by a bus, someone else can take up the mantle and not feel stranded on an island.
-
So, alright, speaking from real world experience here.
Coders shouldn't generally write documentation. It's often a mess. Sorry, coding folks. It is.
That's why you have tech writers. Like me. Mind, it's a shit job market because a lot of the higher ups think it's "useless," but that's for a whole other board.
But that's why you end up with those 4-page deep things because the coder is writing it from his brain. To a coder, those 4 page manuals make total sense. If you, the player, went to the coder and said 'Uh, this is confusing,' he'd probably be annoyed and wonder wtf was wrong with you. He wrote it! It makes sense! He knows the exact line you need!
But to the average person, it's convoluted.
You need that bridge person to write the documentation.
Unfortunately, in a hobby environment, that adds yet another task. It's basically adding another Staffer role/task onto the pile of stuff that needs doing. It's saying: we need someone who can learn every part of our code, what it does, and then write simple documentation for the players and rest of Staff.
As someone who has done this as a career, it's not easy work. A game would have to be a labor of love project for me to go from top to bottom to do so.
So while I wholeheartedly agree that it's a problem, it's not one that's a purposeful one. If you look at the help files for hard-code functions in Penn or Tiny... I can usually make sense of it in the right mindset (like my documentation writing days), but it's just a matter of being in that headspace. Which most people aren't. It's not a malicious thing.
-
I'm stealing @Auspice for my project. BACK OFF, SHE'S MINE!
-
@Rook said in UX: It's time for The Talk:
I'm stealing @Auspice for my project. BACK OFF, SHE'S MINE!
I have my own project!
-
IRRELEVANT.
-
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.
And while my wording might have been harsh, I wasn't talking about any one specific game, since I'm not one to trash a particular game. I'm talking about a general "state of things". 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. This is why in video games and now increasingly even in web design, they specifically hire someone who specializes in UX (This is, of course, not practical in a MU, but I'm emphasizing that it's not easy).
So while I don't expect my thread or even my game to be some kind of grand miracle working savior of the universe, at the very least I want to raise awareness that I and other people see it as an issue. I don't like to think simply in terms of "this is what I want", or "I'll do this specifically for me and my immediate friends". 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.
Does everyone have to agree? No. But regardless, I think that it's helpful. Even if just one person's like "Hey, I never thought about that before", I think that it was worth starting the discussion. 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.
If someone finds my threads or perspective unhelpful, that's fine, not everyone has the same needs. But I don't think that my concerns or perspective are 100% my own either. I have read plenty of things, even things that have nothing to do with this hobby or topic, where someone said something and it changed my perspective, because I never realized something was a problem or that I could do something I'd have never thought to do before.
That said, I don't disagree with the sentiment of doing what's in your power to do, or trying to lead by example. In fact, this thread was inspired by me thinking of how I'm gonna design stuff in my game, and things I've experienced and want to address.
This is definitely an experience I've had, multiple times. Saying something to a coder about something being confusing, particularly in my earlier days, and getting a fairly aggressive or defensive response.
-
@HelloProject said in UX: It's time for The Talk:
But I don't really see where the pride is in not simplifying code syntax so that people can focus on doing things rather than how to do them.
You get literally the same result, except faster. What is the problem with this? There's no barrier, people simply choose not to code a game this way and people have been conditioned to believe that things can't be better.
I would actually say that FS3/Ares is an antidote to this, which may be where some of @Ganymede's early confusion is coming through... FS3 does exactly this, it does all the rolls for you, from initiative through KO, and covers it with a single line giving you the result of your attack and a single line saying whether or not your target was KOed. Yes, you can dig into the documentation and learn how the system itself works (to a degree), but most people don't bother, because they don't need to.
What I'm getting at is that I don't think this is so much a question of "why is nobody doing this," but more a question of "why aren't more people doing this, see, it can be done."
-
@Seraphim73
To be fair, I think Gany's point on that is, it's nearly impossible to DO that for the standard WoD model, with so many variances of what you roll. -
I for one am open and happy to hear how I can simplify things within the scope of what the system is designed to deliver, and what it has to take into account to do so. I am even more open to having someone suggest edits/rewrites of help files! I know for a fact that mine suck, but I have to write something for someone to be able to come along and say "Let's say it this way instead" or to ask questions that lead me to fill in gaps that I myself couldn't see. That goes doubly for theme files, etc.
Coding something "right" isn't easy. Especially large systems. Try coding a threaded BBoard system from scratch, taking into account a base-level @groups system for managing rights and factions. It is complex, hard to navigate through to find a 'good way', and in a lot of cases requires rewriting as epiphanies and breakthroughs happen. To me, it is rewarding. By the time I'm done and it's working, however, writing a +help file on it is daunting so I've gotten myself into the habit of writing the +help files first, then writing the code. I was surprised how much easier and more focused it made me.
-
@Bobotron Yeah... it really is. Both WoD and Saga Edition (two of the other "common" systems) just have too much "am I at point blank range," "can I use Potence," and "is there a circumstance modifier" stuff to have automated combat.
-
I don't think it's impossible to code these things, I just think it'd take time.
If that time is worth it or not is ultimately up to the coder.
Someone also brought up the legality of too many layers of abstraction in WoD/D&D (MUDs get around this by filing the numbers off, much like how D&D and WoD get around what they do by filing the numbers off all the literature they copy).
-
@HelloProject
It used to be that automated systems were what White Wolf cared about -- it turned it into a video game rather than being tools for long distance tabletop. Idk what the status of that is these days, but it was certainly a major issue once upon a time. Muds use mud systems, usually, not a company's IP.
-
@HelloProject
Yeah, it's why we've said 'nearly impossible'. There are things that, unless you REALLY want to bother with them, are much more easily abstracted. And also, probably familiarity in the long run as well. -
@HelloProject A MUD is a very simple system designed for basic combat. It's loosely based on turn based systems, I attack monster, monster attacks me, you occasionally have a few skills to use to shake things up and provide modifiers. The focus on most MUD codes /is/ the combat. It's based /around/ the combat. It's how one advances through the game.
A MUX is something else entirely in most cases. It's an attempt to make a table top system (most of the time) into something that can be played online. The rules are different. The experience is different. The /focus/ is different.
So the code is different.
Can you make an RP MUD? Absolutely, I started on WoT RP MUD's in the very very early 90's. There was some great RP, some great stories, and some fun kill some mobs times.
The focus was still on the combat where with many MUX/MUSH's the focus is on something else entirely and the code is built around that.
There's also modifiers, depending on the system in place. Every turn isn't just attack mob or cast fireball <target>. It's less automated because the variables are much greater. So the code is thus built to facilitate the environment it's in.
If you want an RP MUD, that's great, make one, I'd probably even help depending on the theme involved but you're trying to compare different code sets with different foci.
Hello! Long time listener, first time caller...
-
There have definitely been MUDs where the depth of the actual things you could do far exceeded something like if you fully coded a WoD book, this is primarily the reason I used MUDs as an example. Sure, your basic MUD might be simple attacking and fireballs and such, but a more advanced MUD that approaches or exceeds the complexity of something like D&D or WoD takes those simple concepts and expands on them intuitively.
I don't see any particular reason why the most simple concepts of something like WoD can't be coded and then expanded from there to create an intuitive system that has all of the depth that you'd expect from one of the books.
When I finally have my game up and running, I think I'll just straight up do that myself. I have no interest in actually running a WoD game, but I have nothing against demonstrating what I mean by abstracting the complex systems involved (other than legal issues that won't be my problem since I'm not running such a game).
At the end of the day, I think that's the only way I'll convince most people of my point. Plus it's something to toss into Github.
-
@HelloProject Good luck. One guy has to type attack <target> with <weapon/power/maneuver> other guy has to type defend with <whatever>, then there's the modifiers for willpower, going all out, going full defense, etc.
Sure, you /could/ code that all in, but I don't think it'd actually speed anything up. You're still waiting for one person to decide something and your code would be unnecessarily complex having to /wait/ for the response before it could do /anything at all/.
There are systems were automated code works fine. There are systems where it does not.
To try and say all code should be able to do all things is simply wrong.
Hello! Long time listener, first time caller...
-
@Bobotron MUD always seemed to be closer to the traditional tabletop gaming crowd, whereas MUSHing has slowly been eking towards being a commune for artists. A lot of people that have MUSHed, or still MUSH, have interesting careers, and there's a diverse crowd present. Sometimes it almost reminds me of the collectives of 19th century Europe, where the literati of the day would vacation for relief from stress from their careers or authorship.
-
@Lithium Well, code certainly can't RP for you, but outside of that? Yes, I do believe that code should be able to do everything as simply as possible. I wholeheartedly believe that.
And why should someone have to type all of that? Why can't they just type what they're using and type the target and you have a two word attack? Why can't the person defending get a prompt of the available options and a prompt for the modifiers of those options after that?
You say it wouldn't be faster, but how much time would be saved not spending like 20 minutes trying to figure out the options that are available to you?
The one thing I'd see a lot of trouble with are Mage type things, but there have even been MUDs that coded things as complex as open-ended magic, that were far more complicated than just shooting a fireball, so I know it's not impossible.
With enough abstraction, all that time figuring out numbers, what goes together, if you can use one thing right now or not, could be spent just doing what you wanna do.
Now, an argument could be made for if this, in the context of WoD, breaks the spirit of the game. Like, if working out the numbers and all of that are an inherent part of the WoD experience that shouldn't be removed. But I'm not, like, super invested in WoD or anything, it's mostly an example because that's what people around here are most invested in.
