UX: It's time for The Talk
-
@Sunny This is our monthly reminder to install and play Vampire: The Masquerade - Bloodlines.
-
... wrong thread?
-
@Bobotron No?
-
Sorry, I thought we were talking about Bloodlines in some manner... I am still sick and medicated, please forgive me.
-
@Bobotron I am. Read the post I was replying to vis a vis 'automated systems becoming videogames.'
-
@Tinuviel
Aha, I see why it went over my meds-addled head. Carry on then.On the note of automated user interfaces, my experience with other codebases also points to their stuff ending up with some design cues from the codebase. I've never been on a MUCK that used MUSH-alike commands, for example. So some of it is also codebase differences.
-
To be honest, I feel like @faraday and @Roz's posts cover a lot of what I mean about things being capable of being simplified.
I think what commands are named could be more intuitive. Would that be more confusing if you're coming from being used to a particular command structure? Possibly. But if a game is so radically different from what you're used to theme and community-wise, I think it's easier to accept adapting to those changes, vs. coming from WoD to another WoD game that does everything radically different.
I also think a lot of stuff like needing equals and plus signs and other complex strings could be done away with. In general this is one of those things that I've never encountered in MUDs even when you were, for example, drawing from like five different components of a spell. It didn't require a bunch of crazy ass syntax, it'd just be like <spell> <word> <word> <word> <word>. Any extra shit is abstracted behind the code, not there for the player to type and figure out.
Just, overall, getting down to the very core of my point: Commands shouldn't look like code and/or math (unless the point of the command -is- to do some sort of math). This is specifically why I made the MUD comparison, because a giant chunk of even incredibly complex MUDs typically abstract code and math looking stuff behind a wall that isn't there for the player to interact with. Players interact with basic shit and still get the benefits of the complex but hidden syntax.
Maybe this is too complex of an abstraction for normal MUSH type code, and I can accept that if this is the case (though as I'm planning to use Evennia, I don't really have to worry about that). But just, in general, I don't think that players should have to feel intimidated by syntax, they should be dealing with plain English commands, no symbols or numbers (unless the numbers make sense in a plain English context, like, say, 'eat 10 pigs').
People keep saying that things are impossible, and while it might be impossible for normal MUSH code, it's definitely not impossible for code in the general sense. And I certainly don't think that my desire to make games more approachable to outsiders is "wanting to make a MUD". Like, I again have to repeat, where is the pride in needless complexity if there is something that can be done about it?
tl;dr: No numbers unless they're common sense numbers, no characters that aren't letters. Plain English commands rather than stuff that looks like code syntax. That's how you simplify things.
-
@HelloProject said in UX: It's time for The Talk:
I also think a lot of stuff like needing equals and plus signs and other complex strings could be done away with.
Umm... how? You kinda need the plus in
roll First Aid+Wits
to tell when one skill leaves off and the next begins. You need the slash and equals inmail HelloProject Rook=Some Subject/This is a message.
in order to tell the difference between the recipients, subject and body of the message. Do MUDs just not have these things? -
@faraday Funny, I was actually writing a part in my post about how I can't think of a way to simplify mail commands in MUSHes or MUDs, since they're pretty much the same in most respects (Actually, MUD mail is waaaaaaaaaaaaay more complicated than MUSH mail, usually).
It's something I'll think about more, though I don't have much confidence that I'll succeed.
But yeah, as far as roll goes, that goes back to what I was saying before. I think it very much depends on how much you want to abstract something like WoD or D&D. Like, if you want a roll command at all.
I don't really think that you should necessarily simplify a roll command anymore than that, because a roll command is a math context. Once you get into using rolls, people are generally expecting math, so it makes stuff like plus signs suddenly intuitive.
I would instead ask myself if I want to build my system around people making rolls (I personally generally wouldn't, but that's because I don't plan to make a tabletop MU), or build something for my personal game's needs that tries to avoid anything that seems too math-ish at all costs.
That said, I do have to say that what I'm suggesting wouldn't work as a system. I mean, maybe it could? I think certain MUDs have stuff like that. But overall, as far as systems that you can just plug and play, I do think that you have things down to a pretty hardcore simplicity. I admit that I don't know how your thing works in great detail (though I have played games with it), I don't necessarily know how one could make a system simple like yours with the level of abstraction that I'm suggesting. At least, I don't know yet. Roll is overall incredibly goddamned bare bones and simple.
What I am suggesting, though, is that if someone is creating something from the ground up, and just being like "Alright, lemme invent a combat system for this game", that they maybe aim for plain English stuff rather than strings of characters and numbers all mixed together for a single attack.
To be honest, re: systems, the intent of making my MU was originally because I wanted to design some sort of perfect universal system, then realized it was pretty much impossible to make a one size fits all system. But if one is going to make their own original one for their own unique needs, I think it would be as easy to interact with as possible, on the abstracted level that I'm talking about. If someone is making a tabletop and doesn't want to abstract everything, then just use a sheet and roll and don't make everything needlessly complicated.
I've seen way too many games that don't go all the way to abstraction, but pile a ton of complexity on top of what is basically a simple roll command.
-
@faraday said in UX: It's time for The Talk:
You need the slash and equals in
mail HelloProject Rook=Some Subject/This is a message.
in order to tell the difference between the recipients, subject and body of the message. Do MUDs just not have these things?Technically, you could go for MOO mail...
@mail <name>
| prompt for subject
| then get dumped into a mail editorHonestly, that was one of my favorite things about MOO. editors for mail, descs, even coding.
-
@HelloProject said in UX: It's time for The Talk:
I've seen way too many games that don't go all the way to abstraction, but pile a ton of complexity on top of what is basically a simple roll command.
I guess I just haven't seen that, personally. I think it might help to narrow down what it is you're actually bothered by. I mean, if you agree that things like mail can't be simplified, and rolls make sense, and some things are just an artifact of the way hardcode/softcode works (like needing +who separate from who)... what exactly is it that you see as "horribly crappy" UX?
-
@HelloProject
I dunno. I disagree with your assumptions above, for a few reasons.- I don't think many coders switch coding styles based on from-scratch or hacked/piled-on. You code how you code, and if adding functionality to a system forces you to a style, that's one thing... adding switches to a command, for instance.
- I think most coders I know code the commands to conform with the norms of the game, and make them as simple as they possibly can. When you're talking multiple optional switches, and have to resort to a huge regexp system to sort that shit out, it's no picnic. Coders don't just say "What's the way I can make this all-inclusive as fuck" and just dive in. If they do, I'd have to laugh at them and seriously try to show them that planning your crap out before just tackling a single command is totes the way to go.
- Having the skill and flexibility to code from scratch is huge, in my opinion. It's why it's the only way I work. I don't install other people's code, because my style is wildly different, but it's flexible, easy to debug/expand, and heavily documented. Personal preference.
- As for abstraction, there is a line between abstracting and complicating, as you suggest. I don't see much abstraction on games nowadays, for every WoD sphere has their own unique code, and +sheet systems to parse multiple race data tends to be a lot of @switches and so on.
-
Let's use WoD as an example again. Looking at how roll works, ignoring the fact that we need a + in front of roll for some reason, there's other things where I just feel things could be way simpler sometimes. Like the fact that if you have an ability that adds a particular number to a roll, you can't just type that ability in and have it add to the roll, you have to go look that ability up or find your notes to figure out how much it adds, which is all kinds of annoying as shit when you know what you're using and don't necessarily remember the number.
And, time and time again, even the most slight typo in roll will just make it not work, like, you have to type out a word exactly, you can't even be one letter off, or shorten it for the sake of simplicity.
And, if you are going to use roll, the lack of easy to use macros without knowing soft code is something else I'd say would be incredibly helpful to improving the user experience. Granted, this isn't the most simple and newbie friendly feature, I feel that it'd go a long way in making a game that relies primarily on roll more manageable for a player who figures out how to use it. After a while you end up with your most useful macros and no longer have to constantly type out an entire roll, especially when you have a particularly complex roll. Even Byond Tabletop (a non-MU that functioned on very crude scripting code) had easily accessible macros, and that was back in like 2005.
Like, I feel like these are basic quality of life things.
But in addition to that, you also have to figure out whatever proprietary XP spending code someone uses, which wouldn't be that bad except people tend to name their code the same things as other people's code, but it works entirely differently (multiple kinds of xpspend written by different people). And very few of them are particularly simple, considering that I've rarely encountered XP spending code in a WoD game where I didn't have to constantly go back and check the file.
Speaking of, the bizarre goddamned relationship between +requests and +jobs and just, like, it confuses me for reasons I have trouble articulating, but you'll have games that will explain +requests, and then you have to interact with them using jobs, but then in some games +myjobs is for staff and in some games +myjobs is for players. And then other just really weird shit that gets confusing, especially since, more often than not, these games put staff only commands in the files, and you have to figure out wtf is going on in this wall of text. I don't understand why +requests and +jobs are the same system but use two different commands, as I have seen games that just used one or the other, and also avoided putting staff commands in with player commands, and it was just an overall less confusing experience.
And then there's combat code where you need to learn like a mountain of goddamned unintuitive things. Mega Man MUSH and similar games come to mind. Staff don't care if I say it because they know the combat code is trash already, but it's like the definition of a completely hot mess. And it's not exactly an isolated thing. It seems like whenever combat code gets more complex than roll, people go a bit nuts on syntax and the amount of data you need to keep up with, rather than abstracting some things.
Overall, a lot of code is just overwhelming, there's either too much shit to keep track of or too much involved in doing something incredibly simple. If anything I'd say that Faraday's stuff has avoided this for the most part, but I don't think it's unreasonable to think that it'd be cool if when someone codes something more advanced than that, it maybe not simultaneously get overwhelmingly crazy and difficult to deal with. This is what I'm going for with my MU.
I don't really disagree with what you're saying, but I do think that from a lot of what I'm reading, what I perceive as being a problem is more complex than my original thoughts when I made the thread.
-
@HelloProject said in UX: It's time for The Talk:
Let's use WoD as an example again. Looking at how roll works, ignoring the fact that we need a + in front of roll for some reason, there's other things where I just feel things could be way simpler sometimes. Like the fact that if you have an ability that adds a particular number to a roll, you can't just type that ability in and have it add to the roll, you have to go look that ability up or find your notes to figure out how much it adds, which is all kinds of annoying as shit when you know what you're using and don't necessarily remember the number.
When it comes to rolling on WoD games, I generally type '+roll <number of dice>', or '+roll <number of dice>=<difficulty>' if I'm on an older game. People like to +roll Intelligence + Science, I guess, because they want to prove or verify that the sum of their Intelligence + Science is a number. But if I'm RPing with people I trust, why would I care what their Intelligence + Science is?
-
@faraday said in UX: It's time for The Talk:
@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.
I really think something developers writing games nowadays should do where possible is make a standardized, generic UI library. A standardized method of headers, of footers, etc. This has the benefit of making a standardized method of how things look, as well as allowing easy tweaking (screen reader support, anyone?), and it has one other benefit: you could easily take this standardized 'feed data into this API' method to generate web-based UIs too.
Because I do feel like one of the major benefits that systems like Ares and Evennia provide is the ability to have a web-based interface to things.
As an example, I've written a nice relatively-plug-and-play bboard system for Evennia. Plug it in, and you have a usual more-or-less Myrddin style bboard on game. BUT it also exposes a /boards node on the Evennia webserver, and if you hit that while logged in on the website, you get your bboards as a web forum. Lists all the boards (and how many unread posts are on each), click into one and you get a nice little list of the posts, with unread ones bolded. Click on a post, it marks it read, etc. Post a message there, it shows up on-game with the usual 'New post' type notification, etc.
I think this will be great, because a player will have the option of using the bboards as if they were a normal web-forum, and never having to worry about the @bb/post et al. And I think the more systems we have that way, the better it will be. Because people are used to websites, and web-forums, and so on.
There's a lot of potential for things like that; I want a job system that works like Asana or JIRA, where I can drag a task into a new bucket visually, and get a quick kanban-style breakdown of the current bins. I want a chargen and application system that can work entirely on the web. Etc.
-
@Ganymede But what I mean is, like, if you have an ability that adds something to the science + intelligence modifier, why not just code things so that the abilities add to the roll when you write the ability into it? Like for example +roll presence + manipulation + striking (for striking looks, or some other simple shortcut). It's just weird to me that these games abstract the numbers of attributes and skills, but not everything else, when abstracting everything else would make things easier to roll.
-
Because no one has coded it so that it can be distributed to the WoD/CoD games that use it?
@Thenomain and several others have done HUGE THINGS for WoD/CoD games out there, and make their code available to games that want to use it. If you were to code up something comparable, easier to use, I am sure upcoming games would be banging on your door.
-
@HelloProject
I understood what you were saying. And I guess you could have +roll Presence + Socialize + Striking Looks + Socialize: Formal Events + Applicable Condition + Applicable Discipline. I get that.
I guess, though, WoD is terrible for simplicity. For example, you can't really just type +roll Socialize, because you need to put in your applicable Attribute. And then, you could have the code scan your +sheet for applicable Merits and Powers, but there are so many of them, right?
It's presumed you know your PC well enough to know to hit +roll Presence + Socialize + 2 if you have Striking Looks 2. But, what if the GM doesn't think your Striking Looks should count in this particular case?
So, you have to string out your command. Which is kind of what you were railing against before.
-
@Ganymede Even in MUDs you have to have a long string of words for certain things. Like the bajillion modifiers of a spell, or some kind of complex combat maneuvers. But the point is that it's intuitive.
Roll isn't particularly less intuitive, but roll is also something that you primarily see in WoD games, and isn't so much a system as a basic tool.
In the context of the roll command, roll Presence + Socialize + Striking Looks + Socialize: Format Events + Applicable Condition + Applicable Discipline is, to me, far simpler than having to go and either look up notes or open up PDFs or Google trying to figure out which PDF which thing is from so that you can remember that something is a 2. Despite the long string of variables, this is still significantly less work than how things are currently handled, in my opinion.
You can't eliminate long strings of variables, not from MUDs or anything, but you can eliminate annoyingly complex syntax. This is not an unreasonably insane level of complex syntax. Even the pluses being used in the context of roll makes sense, because in a tabletop context you are adding things together. The plus signs aren't there for arbitrary coder reasons (well, they are there for code reasons, but also for a practical easy to understand non-coder reason).
So, I see nothing wrong with your example, even though it's an extreme example. Because, again, it's waaaaayy simpler than if you didn't have all of that stuff abstracted and had to find the hard numbers.
-
@HelloProject said in UX: It's time for The Talk:
In the context of the roll command, roll Presence + Socialize + Striking Looks + Socialize: Format Events + Applicable Condition + Applicable Discipline is, to me, far simpler than having to go and either look up notes or open up PDFs or Google trying to figure out which PDF which thing is from so that you can remember that something is a 2.
Okay.
You'll be pleasantly surprised to learn that what you're proposing is the status quo, as far as I know.