Posts made by Derp

@Thenomain

Yes. And I dig it.

Editing because you edited: I was actually thinking about the kinds of things that staff themselves would create. Things like the Tix system on Fate's Harvest. This could handle that nicely as well.

@Thenomain said in Straw Poll: XP Spending in nWoD/CoD:

@Coin said in Straw Poll: XP Spending in nWoD/CoD:

@Lithium said in Straw Poll: XP Spending in nWoD/CoD:

for this kind of a situation, I'd actually do something like an XP bank. Where a person could bank xp into a spend. Take Arcane as the running example.

+xp/spend Arcane=6 (to bank 6 xp into it)
+axp/spend Arcane=8 (to bank 8 Arcane xp into it)

Then when you hit the magic number needed for an increase, boom, done. You have new level of arcane.

+axp would stand for alternate xp, so could be used for any splat that had something similar.

I am hella in favor of this, to be honest. Especially if it also locked to a Wait Time, so if you paid for it in full before you could actually buy it, it would just say 'you have bought Gnosis 4. It will be available in a week' or whatever.

I'm flagging @Lithium on this too, because people don't get flagged on every nested comment.

The largest problem with that is the current command structure is this:

xp/spend <trait>=<value>

This sets <trait> to <value> using all Normal XP by default.

I'd also want to let someone say, 'Take the rest of it with <type> xp', which would be the default. For (bad) instance:

...

Wait, how about this?

> xp/bank Arcane=6
You have banked 6 Arcane XP into a future spend.
> xp/cost Strength=2
Raising Strength from 1 to 2 would cost 5 Normal XP. Your 6 Arcane XP (banked) would be returned.
> xp/cost Gnosis=4
Raising Gnosis from 3 to 4 would cost 5 Arcane XP (banked). Your 1 Arcane XP would be returned.
> xp/bank
You have banked 6 Arcane XP for your next spend.
> xp/unbank
Unbanking all XP. Your 6 Arcane XP has been returned.
> xp/spend Gnosis=4
You have purchased Gnosis to 4 for 5 XP.

Whups! You spent 5 Normal XP because you unbanked the Arcane XP.

Better? Worse? Generic thoughts from everyone about this?

In this example, though, how would you mix xp types for those that wish to allow such things?

@Thenomain said in Straw Poll: XP Spending in nWoD/CoD:

I once printed them out and read it at work at a job where most of my job was waiting for something to happen.

That's what I did too! When I was working help desk at the University computer labs. If you were there, you knew what you were doing, so there was no need to bother me.

@Thenomain said in Straw Poll: XP Spending in nWoD/CoD:

You and I are few of the insane people who have read the enirety of the MUX help files.

I read help.txt and wizhelp.txt. Does that count?

To be honest, though, I've been looking at @program for a variety of things. I think it could be very useful. It would take a while for people to adjust to, but for things like, say, Mage spellcasting, where a variety of factors have to be taken into account? It could be invaluable.

@ThatOneDude said in Straw Poll: XP Spending in nWoD/CoD:

@Thenomain Does the old TinyMux let you work with some more advanced level action? For example a basic / entry level Python exersise is to work out question and response logic.

Player types: xp/sp gno=4 <enter>
Print to screen: How much regular XP will you be spending?
Player types: 0 <enter>
Print to screen: How much Arcane XP will you be spending?
Player types: 16 <enter>
Print to screen: <more stuffs>

Or something like that? You then could type out the whole thing with a predefined syntax like: xp/spend <trait>=<level>/<type1=cost> <type2=cost> <typeN=cost> (or whatever) or you could run through prompts...

You could reasonably do this with @Program, though realistically it would just store the answers and send them back to a command for later implementation. So I mean, you could do it that way, but it'd be a longer version of a single command. Might be worth looking into though.

What about something where it could just distinguish certain things, like the roll code does?

xp/spend <trait>=<level>/<type1=cost> <type2=cost> <typeN=cost>

e.g.

xp/spend Prime=4/XP=4 Arcane=12 Tier=4

Though I suppose that the regular would be the default, so you'd really only need to specify the other types and then have it take the rest out of the regular balance, so:

xp/spend Prime=4/Arcane=12 Tier=4

Which then just takes the remaining 4 out of the regular xp pool. Something like that maybe?

I like Liam. I do not like that he is not a romance option for male Ryder.

I would kick Gil off the ship before Liam.

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

@RnMissionRun I went to a place called Big Gay Ice Cream, and they have rainbow Golden Girls art all over the place.

Where is this magical place of which you speak?

@Thenomain said in Date Thenomain:

I'm going to Origins tomorrow.

If you decide to go to GenCon, hit me up. That's my part of the woods. We'll grab a beer.

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

@Apos

Without making this thread, I wouldn't even know half of the things that are even happening, beyond the scope of what I know from my experience as a player.

I'd rather be wrong and learn something than ignorantly try to solve problems blindly while having no clue of where to even start on solving them. With this thread I actually have gotten a huge idea of what things people are trying to solve and what direction one would even go in on trying to solve certain issues.

Some people getting a bit angry, or some people constructively saying "Actually you're wrong", is not like a massive deal.

I honestly don't think this is so much people getting angry, as like... these are things that plenty of people have talked about way more specifically than what's being talked about here.

For instance, the client issue was described as 'relic tech from the 90's'.

Ok, cool.

What, specifically, about it do you think is relic tech from the 90's?
Or, even more helpfully, show us an example of things that you think would work better than what's already out there?

A lot of what's being discussed is cool and all, but it is seriously lacking in the department of specifics. And computers (and the people who work with them) don't do vague. Give them a specific thing to do, like, with a great amount of detail on

1. What already exists
2. What the problem with something that already exists is
3. What needs to be done to solve it

And they will create you something of beauty.

"I don't like it, it could be better," is ... well, just unhelpful, you know? 'More intuitive'. Show an example of what a system you've found to be more intuitive is (an actual, specific example, not: MUDs are way more intuitive. That helps nobody). Tell us about how you would change the look and layout of the client stuff to make it 'not relic tech from the nineties'. What menus would there be? How would they be organized? Etc.

This is the conversation where specificity is key, and we rarely ever get it, so Those Who Do end up spinning their wheels because they rarely think in Vague. People who think in Vague become artists, not computer scientists.

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

If you don't have command echo on, the up/down arrow keys don't do anything.

Ok, so, I just fired up Mushclient again and tested this. The up/down keys work for command recall with or without command echo on.

Bro, like... I don't know what you've done to your poor MushClient, but at this point I would recommend a clean install. It's possessed. If the history commands don't work without channel echo on and it randomly starts doing backward typing type deals, it's possessed, and probably a witch. Burn it. If not for its soul, then for yours.

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

You have to turn "command echo" on in MUSHClient in order to enable your input history. Which means that every single thing you type creates this sort of "shadow" input right behind it. It makes no goddamned sense that you can't have input history without enabling that.

More to come on this post later, but for this part in particular... no you don't. Command history is accessible through... I forget the shortcut, but it is super basic. Either the up/down arrow keys or page up/down.

@Thenomain, I really do think he must have you on ignore.

@HelloProject, let's take this piece by piece I guess:

• Define 'sane tabbing'.
• Potato, among others, has clickable URLs by default. I would almost bet anything Atlantis does too.
• Re: Shadow Commands - what? I don't even know what that means, but ctrl+up, ctrl+down, and Ctrl+z are all things in Potato.
• I have no idea what you've been doing to create GUI issues like that, but Jesus, dude. I've been doing this a couple years now and have never done that. Like... I think you have to be seriously trying to mess it up like that.
• More Intuitive logging system -- okay, that's a good start. I can live with that.
• Pop out spawns and other such -- @Sparks has a whole thread on this already. There are good ideas there.
• Incorporate intuitive material design -- what? You keep talking about a relic from the 90's, but you haven't so far mentioned what is relic-y about it. Talk to us. This whole system is a relic from, what, the 60's, 70's?

Most people don't use most of the features of any client. Like... fact. They have ten million cool things they can do, but it's like... grandma types a note in MIcrosoft word, prints it, closes it. That's about the same level that most users get with their client.

And if you think MushClient is bad, do this on TinyFugue. I dare you.

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

@Lithium I didn't say documentation was evil or unnecessary. But I would challenge you to find a UX book on the planet that tells you to fix UX problems with documentation. (And I've read a lot of them.) Your #1 goal with software is to make it as intuitive as possible so the documentation is unnecessary. When was the last time you cracked open the manual for a PC or web app?

And how many of those books are specifically talking about creating an intuitive GUI? Mu*s are command line games. There is no such thing as an 'intuitive' command line anything. It starts and ends with help. About the best you could hope for in that regard would be to have it as a clickable link through something like Pueblo, I would imagine, or putting the help documentation right in the room, which is essentially 'type me'.

I cannot imagine an 'intuitive' way to create a command line anything.

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

Consider this. Why are people using the MUSH codebases at all?

I would like to follow this up with: Why do people continue to use the MUSH codebases at all, when there have been other people on this thread talking about Evennia and python-systems and things that you can just do in hardcode format?

Part of the user experience is recognizing that people are used to certain ways of doing things, and that these games are not isolated instances, but an entire class of game. @WTFE keeps frothing about good UX meaning that players need never worry about what comes with the game and what has been added to it, but as has been pointed out before, this is simply untrue. You absolutely need to know what comes with the game and what has been added to it because there is an almost 100% chance that the player of this game will eventually move to another game. (The +taxi thing is a perfect example of why users do need to know what comes with a game and what does not).

If it were one game, yes, I could see this argument being sensible, but this is a type of game that you are learning, and so this argument is nonsense.

@WTFE

The @ vs. + vs. . vs bare thing never had an excuse except POSSIBLY the hardcode vs. softcode divide if there's no way to override hardcode commands in softcode. But ... a few questions even if that hardcode/softcode divide needs to be kept:

1. Why prefixes at all? Why is it so necessary to TELL people that they're using soft-coded commands instead of hard-coded? Is it really so necessary to have +finger instead of finger? What does the "+" add there at all?WTFE

Because people need to know where the documentation for this command lives. It's really that simple. That + distinguishes it as a custom command that did not come in the box, so they need to look in the help files for commands that did not come in the box. Mu games are a class of games, with some universal and some custom elements. It is important to keep those distinct, both for players who will go to new games on the same platform and for people wanting to learn the code. +posebreak is nice, but if I want to make a game, I need to either find it, make it, or steal it. That prefix conveys a lot of info. New players might not get that, but older players and coders do. Learning curve.

2. I can see, if I squint right, how @desc me=foo makes sense to distinguish a property from a command, but why is it @ for some and & for others? Pick one and stick with it, dammit! Or even better just make setting a command! set <property> <target> <foo>. And to read it get <source> <property> and to read it in code get(<source>, <property>) and so on.

NOW you are doing what @HelloProject was talking about. This is thinking like a coder. New players have no way to know what those properties are. These commands exist, with their own help files, to explain that. Plenty of us use &whatever me=stuff, but a newbie doesn'the necessarily know what properties the hardcode already knows versus arbitrary attributes. Those files go a long way in helping that.

As for the 'common being the default', in many ways, this is already the case. Many of us use myrrdin's bb system, anomalyjobs, etc. They are common to the point of being default. But they got that way by convention. Most MU systems are not this way. There is no 'common' except as the most basic of systems, and often just a barebones command will give you the most common thing players use it for '+equip bringing up inventory/equipped gear, for instance'. So this is in and of itself pretty arbitrary if more people spend time buying equipment than changing it. What is 'common' to one player is wholly subjective and vastly different depending on experience and investment.

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

My solution would have been to just type <attack><target> and have people automatically enter initiative, then have people automatically leave initiative once the opposing party/person is KO'd. Though obviously I'd have a command to leave combat, just in case everyone doesn't get KO'd, or someone leaves combat before getting KO'd

Ok, so, I guess my questions here are as follows:

• Who are people? When you say 'have people automatically enter initiative', who are you talking about? Everyone in the same room?
• If it's everyone in the same room, how to you opt out of combat if you don't wanna join the fight? You'd have to distinguish the fighters from the non-fighters somehow, and give people a way to join in or back out/flee from the fight.
• How are you defining who the opposing party is? The game doesn't know this. All characters are equal characters.
• How are you defining when the opposing party is knocked out? I'm sure there's a flag or an attribute or something that can be set, but more often than not, MUSH combat does not work like MUD combat, and it's not always easy to define when the opposing party is knocked out.

Those questions need to be answered before we can determine if the system can be made better or not.

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

@Faraday
Shhhh. You've exposed my attempt to bring us back full circle and use the Socratic method to help answer his questions!

I mean, I really think that that's what this discussion is about. Coders already use the simplest possible method to do what needs to be done. No one out there who does code is deliberately trying to make it more complex than it needs to be. The problem is that more often than not the simplest way to do it is pretty damn complex, because you're trying to take something fairly freeform from a tabletop and put it into computer format.

Which is pretty much what @Faraday said.

So I think that short of specific examples, w probably aren't gonna get much movement on this, because there's already a path of least resistance being followed. Not saying that it can't be productive, but just that talking about generalizations isn't gonna get us anywhere.

So, about the only 'universal' things that we can really talk about are the things that @faraday mention above, things that we've actually discussed earlier in the thread. So let my try and make a more generalized point here.

Simplicity is not always your friend. There is a point at which there has to be a learning curve with these games, because what may seem extremely un-intuitive at first glance is actually pretty damn handy.

Let's look at the help system, for instance, as an example. Every MU type game comes prebaked with a set of hardcoded commands and functions. These can be found under the header 'help'. For every flavor of MU*, these files are universal. I know that if I go to a MUX, there will be a 'page' command. I can use @emit to post things to the world. Etc.

But then there are these pesky +commands, and +help. Wtf is that about? Why can't we put our +drive command, found under +help, under 'help drive'? By god, that would make it easier, right?

Except, no. It wouldn't. In fact, it would create complications. What if I go to another game, and try to 'Drive <somewhere>'. The game tells me 'huh?' Well, what kind of jank shit is this? It worked on this other game. Why is it not working here? 'help drive' gives me nothing. And when I type 'help', it pulls up a list of stuff that I've never even seen before. Jesus, now I have to navigate a whole new help index.

So... what if there were a way to distinguish commands that we add (+) through softcode from other commands that just come pre-baked with these systems? We know how the pre-baked commands work, we just need to know how the new stuff works. It could even have its own additional (+) help system, to keep it cleaner.

And that's what I'm talking about, here. On the one hand, yeah, sure, it seems pretty counterintuitive to someone looking at it for the first time, but to anyone who's been around a while? That is nicely packaged, and pretty intuitive. Because there's a learning curve that is pretty much necessary for these systems to function well.

Just like video games. Many video games are not point and click, or whatever. Tekken is one of my favorite games. Sure, at first it seems simple. I hit this one button and it does this thing, I hit another and it does another thing. And really that's all I need know, if I'm patient and lucky and masochistic af. But man can I really make that baby sing with that ten-hit combo whose formula requires three lines on the TV to follow.

So there has to be a line, somewhere, and across these kinds of games, stuff like that does tend to be that line. It requires some investment to learn how these things work, but just because it seems confusing at first doesn't mean that it's not the best way to do it, either. It's not 'shitty design', it's pretty damn handy. But it also takes practice.

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

@Rook I feel like most players would know what they're adding together though. Like, even though I'm shit-tier at WoD, I generally know what my stuff is even if I don't usually remember all the numbers.

Is it usually the reverse and I'm just weird?

edit: Also you mean in most WoD MUSHes.

So, like... I'm still not sure what you're wanting here. You seem to be asking for a lack of complexity, but what I'm seeing is that generally you don't want to have to go look up stats and stuff.

But that's not what these command systems are -for-. These games aren't being created so that you never have to buy / read the books and can just do the thing. They're not video games. They're tools so that people who have already read the books and know the source material can come together and play online.

How would it be different at a tabletop if you didn't remember that striking looks 2 gives you a +1, and Striking Looks 4 gives you a +2? You'd still have to go look those things up. These coded systems are in place basically to help you use what you should already know. For a roll command ,the simplest version would be +roll stuff, and then if you have 9-again or whatever you count those and +roll stuff again, until you're done rolling. We do create some shortcuts to make it faster, but those shortcuts don't negate your need for the materials. Most games out there specifically say that you need to both own and be familiar with the materials presented. And that's not just WoD. That's DnD. Pathfinder. Exalted. Superhero games. Whatever. If they're using custom material, they still pretty much insist that you be familiar with the material.

So is your idea of 'simplicity' such that you... won't ever have to go look in a book again? Because that's pretty much not gonna happen. Ever. We can try and streamline the tools out there to let you put stuff in faster, but no system can ever negate entirely the need for the human brain.