UX: It's time for The Talk
-
Used to be that both White Wolf and Wizards of the Coast had serious issues with systems that removed the need for the books. Sheet and dice code was OK, automated combat was not. Idk if that is still the case, but it was a major consideration when we were doing code on Ashes.
-
Tools that add depth and complexity don't have to be insanely difficult to use.
We don't, for example, make hammers with handles covered in glass. What does the glass add to the functionality of the hammer to do complex things?
-
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.) I think that @HelloProject's original post is totally correct. There's tons of coded stuff that we all have gotten used to being kind of unwieldy that could actually be super simplified and made easier.
-
@HelloProject said in UX: It's time for The Talk:
I can't see any particular reason why people would not want it to be simpler to do the things they're already doing. Unless you're talking from the perspective that I talk about rice cookers. I only hate rice cookers because I think they're lazy as shit when you can get a pot and learn to cook some freaking rice. 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.
Let me try to explain this in another way.
The number of headstaff on CoD games in particular that are also code-savvy is miniscule. In many cases, game owners rely on coders, and it has been this way for quite a while. We can all agree that it would be great if the headstaff was also conversant and capable in code, but that's not always the case. My understanding from my limited MUD experience is that the headstaff were.
I'm not conditioned that things can't be better. I'm conditioned to accept that unless I want to devote the time and energy to learning code, I will be relying on someone else. And I'm not going to lecture that someone else on what is or is not difficult to do. That's a very good way for me to lose my coder, and I'm not in a position to do that.
And for the record, I use rice cookers when I don't want to spend my energy focusing on cooking the rice.
And to the potential question of "who are you to say what is better", I'd say that anything that harms no one, makes doing something simpler, and gives you all of the options you had before without the mess, and most likely faster than before, is objectively better.
Excellent. Then do it. Why are you here attempting to lecture us?
Go. Do it. We'll wait.
Alright but I'm interested in lowering the barrier to entry into this hobby, and getting rid of all the nonsense people think is perfectly acceptable, which is why I made this topic and other topics. If you're not interested then what do you solve by expressing your disinterest?
I'm solving as much as you are by posting. I'm providing a reasonable counter-opinion here.
You talk about lowering the barrier to entry by improving user experience, and then hook on improving or simplifying code. I previously stated that you could improve user experience by enhancing communication of commands and processes, but this has nothing to do with code syntax. I more recently stated that I'm more interested in ideas that improve the user experience through game policies that add interesting RP elements, like politics, an economy, etc., but this also has nothing to do with code syntax.
And, as said above: if you are a coder, fantastic. Go and improve our commands and code, please, by all means. But it's not my focus or interest because I lack that skill set, and I'm not going to start rattling a cage for something I cannot do myself.
In the mean time, what I will do is suggest and propose things that I can implement, if I had my own game.
“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.
-
@HelloProject said in UX: It's time for The Talk:
Tools that add depth and complexity don't have to be insanely difficult to use.
We don't, for example, make hammers with handles covered in glass. What does the glass add to the functionality of the hammer to do complex things?
You're absolutely correct.
You should write them.
-
But this is why I put this in the code part of the board, to address coders. Obviously I know that game owners who don't code can't do shit about it, but addressing coders and opening up a dialogue can.
I never once implied that anything was the fault of owners who don't code, or that it's the responsibility of MU creators to talk to their coders about anything, so I don't really know where that assumption came from. As far as I can tell, I've only been addressing coders, so what is the problem?
-
@Rook said in UX: It's time for The Talk:
. They use the same systems, the same code, the same OOC grid layout, the same CharGen...
The fact that our chargen doesn't need a specific room in which to do chargen has confounded a lot of folks. Some folks like that you can just work on stuff while chilling in the ooc room; others hate it. One simple change threw a lot of people, even though folks adapted.
There is something to be said for similarity in grid design as well. You don't need to learn a new one anytime you log into a MU*. OOC room, quiet room, etc; that doesn't need to be reinvented. 20 years of ooc grid design has spit out systems that work.
People bitch about cookie-cutter WoD, but personally I just wanted a game in which I could play WoD and have my jobs not take a month and a half for a yes or no question, and where I didn't get shat on by staff for playing a template right out of the books or refusing their rapey dogpiling. I didn't want to reinvent the genre.
Heck, when we were deciding on which system to use, most players begged us to not update to 2.0. GMC was about as far as folks wanted to bend, even though XP spends are SIMPLER.
-
@HelloProject said in UX: It's time for The Talk:
As far as I can tell, I've only been addressing coders, so what is the problem?
You don't see it? Okay.
You're not an experienced coder. I don't think you ought to lecture coders on their practices, as if they had not thought of it already. Because you're not an experienced coder.
Don't piss off the coders.
Instead, focus on what you can fix. Like policies, communication, grid design, administrative systems, wiki entries, etc.
Or, just design your own codebase and fix this whole barrier of entry thing through your own efforts.
-
Very giving staff
I'd say that a LOT of it is the conceptual model of 'STAFF CAN'T DO ANYTHING COOL ON THE GAME' causing the lack of staff to actually make things manageable. You need X staff for Y players, after all.
-
@Bobotron just don't hire wankers. Staff should be able to play, too.
-
@Paris said in UX: It's time for The Talk:
@Rook said in UX: It's time for The Talk:
. They use the same systems, the same code, the same OOC grid layout, the same CharGen...
The fact that our chargen doesn't need a specific room in which to do chargen has confounded a lot of folks. Some folks like that you can just work on stuff while chilling in the ooc room; others hate it. One simple change threw a lot of people, even though folks adapted.
Personally I think it's a pretty interesting innovation that I liked, without the hassle of going back and forth through rooms to change things, even though I think a walk-in chargen is a bit more newbie friendly.
@Ganymede said in UX: It's time for The Talk:
@HelloProject said in UX: It's time for The Talk:
As far as I can tell, I've only been addressing coders, so what is the problem?
You don't see it? Okay.
You're not an experienced coder. I don't think you ought to lecture coders on their practices, as if they had not thought of it already. Because you're not an experienced coder.
Don't piss off the coders.
Instead, focus on what you can fix. Like policies, communication, grid design, administrative systems, wiki entries, etc.
Or, just design your own codebase and fix this whole barrier of entry thing through your own efforts.
I am, in fact, making my own game that addresses these issues, and am coding the game myself because I have my own ideas about how things should be done.
I have absolutely no qualms about pissing people off by saying unpopular things that I believe need to be said, because I'd rather be loud about what I view as detrimental stagnation, than quiet in the hopes that I don't piss people off who I might need a favor from.
If people are so vindictive that they won't work with me because I said the current state of MUSH code design is pretty much trash, then I quite honestly would not want their help to begin with, and will just figure out how to do something myself.
I don't need to be an experienced coder to see with my own two eyes that things are needlessly complicated and could be less complicated, just like I don't need to be an experienced film maker to say when a movie is trash, or an experienced writer or literature expert to say that Moby Dick is a trash ass book and that Herman Melville can't write for shit.
If you're not up for opening a dialogue and your entire point is to silence when people speak out on something they have an issue with, then I would argue that you are not being constructive, but needlessly detrimental to potentially productive communication.
If you don't have anything to add except "Be quiet because people might get mad", then you don't have anything to add except attempting to silence what I believe was a fairly constructive criticism on my part. And considering that you yourself are not a coder, I don't really see why you're getting all into your feelings about something that was not even addressing you to begin with.
-
@HelloProject Yay!
We let players be able to raise most stats as they like (provided they have the xp) without staff needing to authorise it to speed stuff up, too. We're not perfect, but felt that some of the gatekeeping about justification was unnecessary busywork.
So, parts of our code were designed or adapted to try to remove staff as a barrier between players and RP.
-
@HelloProject said in UX: It's time for The Talk:
I don't need to be an experienced coder to see with my own two eyes that things are needlessly complicated and could be less complicated, just like I don't need to be an experienced film maker to say when a movie is trash, or an experienced writer or literature expert to say that Moby Dick is a trash ass book and that Herman Melville can't write for shit.
You can say what you want. Your experience and insight is what gives your words weight.
I await the anticipated success of your project to convince coders to change their ways. I'll be over here, doing what I can do to make the user experience better.
“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.
-
The point of a discussion isn't to have some 100% success rate in saying "I'm right and you're wrong", the point of a discussion is to state a point of view and express why you have that point of view, or perhaps go into more detail about that point of view.
Your entire argument seems to be "We shouldn't have this discussion", which is why my argument is "Then why are you in it?"
edit: Well, that's more of a question than an argument. It's a questrument.
-
We should all be in it! Free speech! People's rights! Down with the Patriarchy!
HelloProject, are you the Patriarchy?
-
@Tempest said in UX: It's time for The Talk:
We should all be in it! Free speech! People's rights! Down with the Patriarchy!
HelloProject, are you the Patriarchy?
I do have a penis.
-
There is an issue of Mux/Mush having hardcoded and softcoded commands, so redundancy in 'help', '+help' and '@help' comes from that. I may at some point go over help files (I am not not not a coder) and try to update along the lines of 'to get syntax, type x, to get an explanation of the function, type y, etc'.
-
I think that there should be new ways of doing things, absolutely. Things like helping non-MUSHers learn how to MUSH, for instance, on your game is a very valuable thing that might not get used but once, but making a new MUSHer is the holy grail of our goals as game-runners... or is right up there. So I'm all for teaching someone who is excited, curious and willing to take on the slight learning curve because let's face it, the mechanics of MUSHing is miniscule once you've MUDded.
It's learning how to Roleplay that most people have the most trouble with.
-
@Paris said in UX: It's time for The Talk:
There is an issue of Mux/Mush having hardcoded and softcoded commands, so redundancy in 'help', '+help' and '@help' comes from that. I may at some point go over help files (I am not not not a coder) and try to update along the lines of 'to get syntax, type x, to get an explanation of the function, type y, etc'.
The hardcoded commands of like MUSHCode and MUXCode and stuff are some of the most confusingly written files in the goddamned universe. Definitely written for coders by coders, not the end user.
@Rook said in UX: It's time for The Talk:
I think that there should be new ways of doing things, absolutely. Things like helping non-MUSHers learn how to MUSH, for instance, on your game is a very valuable thing that might not get used but once, but making a new MUSHer is the holy grail of our goals as game-runners... or is right up there. So I'm all for teaching someone who is excited, curious and willing to take on the slight learning curve because let's face it, the mechanics of MUSHing is miniscule once you've MUDded.
It's learning how to Roleplay that most people have the most trouble with.
Yeah, that's the thing, the mechanics of MUSHing are significantly simpler than MUD, which is why it's outrageous that MUSHes often have more difficult to figure out commands than a MUD.
-
@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.
