I have not read through all of this.
One of the design considerations about WoD/CoD is how conditional it is. If these conditions -- and I am not even talking about the conditions game mechanic here -- were constants, it would be easier.
They are not. They can be as capricious as 'I feel like using my use-once monthly bonus now'. Yes, there are definitely ways that you could code that and track it. Now multiply that work for the dozens of things to which this applies, few of which are handled in anything even resembling a uniform manner.
The system is explicitly designed to be as versatile and flexible as possible, and is heavily reliant on judgment calls to be made on the fly. Which is why you have the roll setup that you typically see; the game is designed for a single ST and a tabletop environment, unless someone is using the LARP rules instead. That there are different rules for the same core concepts of a game for tabletop and LARP alone is significant, in that it recognizes that the tabletop version has substantial issues when someone tries to directly apply it in a LARP environment, and the same holds true for a MU environment (even if some of the problems vary somewhat).
This is one of the reasons it can be great for MU if people all know the rules and don't mind the code complexities designed to preserve as much of the intentional versatility and flexibility as possible of the tabletop experience, but that I feel it's a bad choice for a system to use if you want one explicitly for use in an MU environment for this same reason. WoD/CoD can be streamlined in its code, but doing so generally will also require some mechanics or rules shifts in the form of house rules -- which means you just replaced more complex code commands with a new pile of rules and exceptions to learn.
I'm not saying you aren't, just saying that it's not really a player problem. Players are kind of at the mercy of coders.
The fact that WoD and many other systems aren't made for a MU, is a part of why I'm trying to design my system to be MU specific, even if it's taking inspiration from lots of different things. I think a MU specific system will be an interesting experiment.
It's not like people have never made MU specific stuff before, there's plenty of examples, but I honestly haven't seen progression systems that truly take the long-term nature of a MU properly into account. Like, the best example is XP catch-up stuff. But yeah, WoD is really not made for a MU, and there aren't really ways to get around those problems without WoD just straight up not being WoD.
I realized while designing the progression and combat system of my game that the problem isn't necessarily XP, the problem is actually attributes and the way that these tabletop games look at combat. It's not something I considered until trying to figure out how to avoid power bloat/creep, since common wisdom has always been that XP is the problem.
@HelloProject That's why I decided to not bother with WoD/CoD any more, either.
In my view, it is easier to write something from scratch that works for the capabilities of the environment than force a square peg into a round hole. It's what I'd been working on for about 2-3 years now practically, and for about 10 years or so before that as an idle tinkering game project.
On the redundant commands and hidden indexes and all that issue, this is one of the first things I was working on addressing.
@HelloProject said in UX: It's time for The Talk:
I'm not saying you aren't, just saying that it's not really a player problem. Players are kind of at the mercy of coders.
And coders are at the mercy of players and staff. Do you think that a coder who says, "I'm going to code this way no matter what you think?" is going to have a successful game? There are better systems to code under and they are not anywhere near as popular, if they can even get off the ground. That is not a code issue, that's an end-user situation, a player issue.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos
I guess I keep going at it from the perspective of the coder also making the game.
That isn't my intent, but for some reason that's where my brain keeps going.
Doesn't matter @HelloProject why the coder is coding, just that they are coding. The audience doesn't change - you're always coding for the users of your code, not yourself. That's the point.
You can code up the coolest cockamamie thing that no one uses, and guess what, zero people still use it no matter what the command interface is.
Functionality will win over people, who will deal with complexity when they understand that the complexity is needed.
@Rook said in UX: It's time for The Talk:
Doesn't matter @HelloProject why the coder is coding, just that they are coding. The audience doesn't change - you're always coding for the users of your code, not yourself. That's the point.
And this is the answer. If you decide to make a game for the Anime crowd, you still have to look at your audience, whether it's policy, descriptions, layout, or code. The final part of the triangle is: Headstaff is at the mercy of players.
Not the coder. Not other staffers. But absolutely the players. Some games can get away with treating some of their players like shit because they are offering a limited product or there's enough people to keep them afloat, but that's the kind of symbiotic relationship that you want with your players.
But if players don't want to use a certain bit of code, they won't. Players will put code on themselves to turn 'where' into '+where' if that's what they're used to, or help people create macros for their client of choice. They will do this in spite of you or what you want.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos
Oh, so you're kind of saying what I usually say about designing a game for your audience.
I guess I never thought of it in the context of codebase choice. (Except MOO, fucking MOO)
This is probably a MU challenge I'll have to keep in mind.
@Thenomain said in UX: It's time for The Talk:
Players will put code on themselves to turn 'where' into '+where' if that's what they're used to, or help people create macros for their client of choice. They will do this in spite of you or what you want.
Truth.
I literally typed whisp <whoever>=<blah>, cursed, and then typed whisper <whoever>=<blah> on Arx so many types, I just added a 'whisp' command to myself that does whisper for me, using the Evennia command alias system. Not because whisper is wrong and whisp is right, but because after years of having MUSH accept whisp, I honestly cannot break that muscle memory.
MUX/MUSH usually accepts 'w', too. Aliases at the server level are a grand thing.
@Rook said in UX: It's time for The Talk:
MUX/MUSH usually accepts 'w', too. Aliases at the server level are a grand thing.
To be fair, Evennia has server-level aliases too, and it will even automatically alias all the helpfiles. It's just that whisper is not a command that has those server-level aliases built in. (But you can add your own user-specific aliases using the nick command.)
@faraday said in UX: It's time for The Talk:
So yes, it sucks. But I really don't see a good solution that doesn't involve gutting the way the hardcode works. That's something the hardcode devs can help with, but it's beyond the reach of the average game admin/coder.
Made this possible with Rhost with dynamic help files you can create on the fly then access with textfile(), dynhelp() or @dynhelp in your code.
You just need to create two server side files to make it happen.
whatever.txt and then mkindx it for a whatever.indx.
There's also a corresponding mkhtml that you can convert a whatever.txt and a whatever.indx file into an HTML translated file with built in indexing.
I've always believed the solution for the nitch environment is providing an environment that is flexible, that can be easily maintained, and easily modular to go in nearly any direction the admin want it to go.
We're close to that end point, and it's a moving target so I doubt we'll ever reach it. But it's been a fun ride getting there and every day we think of new things to add for modularity and configuration control.
With how the world is going with direction with containers, cloud computing, virtualization, dynamic start-ups and any number of other things, environments and codebases generally have to follow the pattern at the back-end or frankly be left behind as people choose things that will do it.
It's a tough target to keep up with.
@Thenomain said in UX: It's time for The Talk:
Then let me explain from history: Because @commands.
I believe the very first +command was Firelizard Mail, an object-driven messaging system from before the days of a Master Room, before user-defined attributes. It was an amazing feat of coding in a limited system, and it eventually became +mail, especially when we got Brandymail.
So we have '@dig', '@link', and all those @-commands which have to do with server-changing functions. Then you have 'page' and 'move' and 'pose' which are all user-facing server commands. Perhaps '+mail' should have been one, but we created a third category: User-created commands.
And it's a category that's absolutely meaningless to the user. The user shouldn't have to give a flying fuck if "mail" is a built-in command or a user-created command. It shouldn't make any fucking difference to the the UX. (If it does, you fucked up the command.)
In part, I've invited this discussion. '+' is silly, but it's silly nowadays, not silly then.
It has always been silly. There has never been a need for users to distinguish between hard-coded or soft-coded commands. There has been crappy software, maybe, which forced this distinction but ... that is the very DEFINITION of poor UX.
"QUIT IT, you moron!
Accidentally forget the opening quote and ... oh, right. Nothing happens.
... I have no idea what you're talking about here. I suppose that no, this doesn't look familiar.
The retro-explanation for "+" being a good thing was:
Nobody starts a pose with +. So it's a lot harder to accidentally run a fucking command when just trying to RP.
So I alluded to what happens if you pose something that begins with a command (QUIT in this case) and accidentally forget the opening quote. (Hint: nothing.)
And this also flies in the face of the number of built-in commands that don't start with @ or + anyway like look or page or … The "reasoning" is bullshit and is reverse justification for a stupid design decision.
@WTFE said in UX: It's time for The Talk:
It has always been silly. There has never been a need for users to distinguish between hard-coded or soft-coded commands. There has been crappy software, maybe, which forced this distinction but ... that is the very DEFINITION of poor UX.
This made me laugh.
Aside from soft code varies from game to game? No reason at all to distinguish from hard-code, that is constant from game to game, and user commands, built within individuals game and unique (used to be) to those games?
I remember the days all users were expected to contribute their own content. Whether making rooms, their own vehicles, their own multi-descers, some new coded game for the game room, or new potential globals? Whether or not pool tables or bowling alley code on Mu*s was ever needed, users had liberty to make these and they did. So yes, there has been and still should be, a need to distinguish hard-code and soft-code commands.
Users should understand because WoD LA Nights has +taxi to get around, that doesn't mean CoD LA by Night will have any taxis at all. There is absolutely reason to distinguish.
I'm just a surge protector doing my job, sir.
The "reasoning" is bullshit and is reverse justification for a stupid design decision
The "reasoning" given so far is wrong.
@-commands are designated with an @ symbol because they modify the database in memory or on the disk and are meant to be used by game admin. (Saving counts as modification)
Commands like look or page are part of a specific category of user commands that manipulate the database and occasionally modify it. (look, for instance, does a room description lookup in the object database, while quit will save your player file to disk)
The + syntax was born as a way to indicate a command that was added by that specific locality - where locality could mean game, owner (in relation to current thing) or some random coder.
And it's a category that's absolutely meaningless to the user.
I don't think you're wrong. It can be removed. Actually, removing it takes all of 5, maybe 10 minutes of work. If I do that however, what should the new standard be? Does everything have a + now? Is it all just the command with no @/+ or what have you? Do we keep the @commands and remove their @? Now we have reserved keywords. You can't have your own commands called, for instance: switch, flag, channel, set, create...(This is a large list)
@HelloProject I think one of the disconnects here is that you're comparing MUDs to MUSHs. The tools available to both are different. The fairest comparison we could have between the two would be any random MUD and Evennia, since Evennia allows us to code in a useful programming language with useful paradigms (insert @Griatch here). MUDs are primarily coded in hardcode. Mostly C, sometimes C++ recently, occasionally Java (I know right? I've seen them though) and I've seen at least one Pascal MUD. They're set up, from the beginning, to support a coder adding new features to their hardcode. Most MUDs also support a rudimentary coding language inside the game itself that is usually referred to as just <insert object type here>PROG. Even that is a better tool than MUSHs have access to. In contrast, your average mush developer has to use the built in lisp like language to do everything. You may say, Why don't you just add to the built in hardcode then? I'm glad you asked.
You'll remember where I mentioned that MUDs are typically designed to facilitate modifications to their core systems in hardcode. MUSHs are not designed this way. Evennia is the only MUSH like system designed from the ground up to be modified at the hardcode level. I'm sure that @Ashen-Shugar will jump in at this point and hold up his RhostMUSH sign. He's not wrong, but it's an advanced code base. Your average MUSH code base, however, is designed in such a way that adding new features to it requires modifications of several built in systems. Unlike in our previously mentioned MUD code base, these systems are spread around and sometimes, they're dynamic. It can be, at times, annoying to add new hardcoded features.
But what about the UX
I don't disagree with anything in particular that @faraday said. Too many commands do have inconsistent and redundant usages, especially on a large game like the reach. That was less a factor of the game system, however, and more a factor of how many different coders touched the reach. Thenomain and I talked to each other and kept our stuff consistent. We could also stop using MUSHcode, that would help a lot. RhostMush and Evennia have much better systems for coding.
Question about why +roll Shorthand Word doesn't work for WoD
Answer: Did you mean Academics, Academics.Accounting, Academics.Pre-Law, Academics.Pre-Med...
I've seen soft code that has multiple variations as to what can be put behind it. Using QUIT is a strawman because A) That's a hard coded command built into the hard code and B) It would be insanely easy to write up a piece of code that used a simple word that needed qualifiers and then you end up with coded failure messages (if one's even in place, you'd be amazed how many people don't put failure messages in place) and C) Not all code is written at the same skill level where people may, or may not, have the proper identifiers or checks in place to make sure code doesn't run. Depending on the code it's also possible to have it do effects to sheets, or automated commands. "Attack <insertnamehere> as a say action suddenly could become a combat action. Let's not pretend that /anyone/ has perfect grammar a hundred percent of the time.
There is also the defining terms, +news can be the same as NEWS, but it could also be something else entirely. That depends on the function involved and what it's designed to do. +news could be a command to read IC news posts about what's been going on, where as NEWS could be the games theme files, setting files, who knows what else it could be.
By using the + it also helps to /designate/ what is and what is not a coded command. It lets the player know that they are now using a chunk of code with a determined purpose based on the coded command action.
The more you automate. The more you streamline. The more opportunities you get for coded snafu's or unintentional happenings.
Is it ideal? Maybe not. But I don't code around the idea that everyone is prescient and omniscient knowing every command and never makes mistakes. I code around what is familiar and accepted, because it is familiar and accepted, and thus easy to use.
If someone is new to MU*'ing then learning to type +roll is no different than typing roll, or whatever else you want to use an example it's still going to require educating the newcomer.
Maybe I'm a dinosaur.
Maybe I'm set in my ways.
But +code? I don't see what's the big deal honestly.
Hello! Long time listener, first time caller...
@Lithium said in UX: It's time for The Talk:
But +code? I don't see what's the big deal honestly.
You've obviously been playing for awhile so I'm sure it's no big deal to you. But put yourself in the shoes of a new player who's never MUSHed before. Imagine you're trying to learn this command set for the very first time.
You naively type help. Great - there are some help files. One of them mentions a mail system. Awesome! You start reading and try to use something.
Oh but wait... @mail is disabled on this game, so all those help files are completely non-applicable. You have to know to go look over in +help to find a whole other set of commands you should be using for +mail.
The next day you type WHO to see who's online. Ok, you get a list, not so bad. But wait... there's this completely separate +who command that would've given you so much more if only you knew it was there.
Now that you've gotten used to all these +-commands, you try to describe yourself. But wait, there's no +desc. You have to use @desc. Now you find yourself having to remember which prefix to use for which command.
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.
Incidentally @Alzie, Ares is also coded from the ground up to be modified at the hardcode level. It has no softcode system.
@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.
What is obvious to you may not be obvious to me and vice versa.
I've been in this hobby for a decade+ and still don't realize there's a far superior +who until like months in, if I'm lucky.
@Groth Personally I would have the 'help' system contain only the help for the player commands. Code documentation can live elsewhere.
I fail to see how extending the 'mail' command to do something more (what I'm suggesting) is any more confusing than disabling it and forcing players to use a +mail system instead (which is what people do today). The player doesn't care whether it's softcoded or hardcoded; they just want to send mail.
Oh, so you're kind of saying what I usually say about designing a game for your audience.
I guess I never thought of it in the context of codebase choice. (Except MOO, fucking MOO)
This is probably a MU challenge I'll have to keep in mind.
