Optional Realities & Project Redshift

[Derp]

@HelloProject said:

@Groth I guess I should say complicated syntax, then. But either way, an extremely simplified dig command would be:

dig

And then prompts pop up asking what you wanna do and what to type in to do it. Preferably something like north/south/west/etc. Then prompts like what you want the name to be, etc. Dig would initiate a series of prompts, so the only thing you'd need to remember is to type dig to begin with, and everything else is just handed to you.

See, what you're talking about here is something more properly covered under something like @program, wherein you type a thing and a series of prompts comes up asking you for input. That's more than just a single command, though, it's a series of things executed in order that then compiles a final result.

As far as a single command goes for digging, @dig is about as simple as it gets for what it does.

[SparklesTheClown]

@Groth said:

I think the main reason there's not more prompts at least in PennMUSH is because PennMUSH does as far as I'm aware not have any real support for prompts. Having back-end support for prompts would help a lot in that regard.

Yeah but I never said anything about doing this in PennMUSH, or MUX, or anything along those lines.

@Derp said:

See, what you're talking about here is something more properly covered under something like @program, wherein you type a thing and a series of prompts comes up asking you for input. That's more than just a single command, though, it's a series of things executed in order that then compiles a final result.

As far as a single command goes for digging, @dig is about as simple as it gets for what it does.

I just explained how it can be exactly way more simpler than that, by doing it exactly the way I described.

[Groth]

@Thenomain said:

"It's easy, once you know how."

This undermines the idea that it can't be simpler. Simplicity compliments flexibility. Flexibility does not compliment simplicity, unless we're talking about redundancy then (through some irony that works) it does.

Which is to say: I think you're trying to push an agenda. Enjoy!

The problem here is that we're trying to pretend as if 'simple' has a single definition. Simple depends entirely on context, simple to read and simple to write are not the same thing, see for instance Stenography.

If a user that understands the commands want to dig a dozen rooms, none of the suggestions that you or @HelloProject have proposed are easier to use then @dig. If a user has never dug a room before, then the command prompt approach will be easier however would you want to go through a multi-step prompt every time you want to dig a room? Probably not, you want @dig.

Any attempt to write a simple and flexible CLI command to dig rooms will look remarkably similar to @dig.

[Derp]

@HelloProject said:

@Groth said:

I think the main reason there's not more prompts at least in PennMUSH is because PennMUSH does as far as I'm aware not have any real support for prompts. Having back-end support for prompts would help a lot in that regard.

Yeah but I never said anything about doing this in PennMUSH, or MUX, or anything along those lines.

@Derp said:

See, what you're talking about here is something more properly covered under something like @program, wherein you type a thing and a series of prompts comes up asking you for input. That's more than just a single command, though, it's a series of things executed in order that then compiles a final result.

As far as a single command goes for digging, @dig is about as simple as it gets for what it does.

I just explained how it can be exactly way more simpler than that, by doing it exactly the way I described.

Right, but what you described is a program, not a command. Yes, a digging program could make digging simpler by using an interface like that, assuming it's set up in such a way to allow for all the things that the single-line command can do, but it's still a program that just takes what you feed into it and puts it back into the single line command above.

I get what you're saying, it's just that it's not actually accurate.

Think of it like this:

@dig Kitchen=Kitchen;K,Out;O

Under your version:

dig

$ Name of the room you're digging?

Kitchen

$ Return Exits?

Yes

$ Number of Exits?

1

$ Name of Exit?

Out

$ Alias(es)?

O

And then it just takes and plugs all of that information back into the thing from the start. The reason that we don't do this (IMO) it because it's not as fast to do it that way, and tends to lead to some confusion on things like ... where these exits go, unless you already know how the first command words and what you're feeding into it, or an extraordinarily detailed help file was written describing basically all the things that help @dig already does.

This is what I mean when I say things like 'coding for the LCD is not necessarily the best option'. There is a certain level of investment that you have to expect from the end user in these things, or else you end up with nightmarish systems and books full of information on how to use them.

Edit: Forum formatting grrr.

[Thenomain]

@Groth said:

The problem here is that we're trying to pretend as if 'simple' has a single definition.

Then this discussion about how @dig is already as simple as it can be is conceded as "stupid", and we move on.

[Jaunt]

Simple and intuitive aren't the same things. While there are definitely things that could be designed more simply for MU*s (which could be either a good or a bad thing, depending), designing commands that are more intuitive is a definite positive.

It's the whole learning curve thing. I don't think that you need to sacrifice functionality for ease of learning. I just think that, often-times with our engines, functionality could be a lot more intuitive than it currently is.

For instance, while I don't find @dig to be a hard-to-use command (especially with macros/aliases), I can't say that it's very intuitive at all.

I think that the prompt idea is interesting. If you could make a prompt system that was optional (for instance, only used if you typed "@dig" by itself), and was designed to actually help teach you how to use the @dig command (by showing you the new sum output for each step, highlighting the additions or some such), then I think you'd be onto something.

The prompt would be slower, but very easy to understand and use, and it would teach you the faster, less hand-holding way to accomplish the same thing. To me, that's intuitive.

[SparklesTheClown]

@Jaunt A training wheels approach is certainly interesting. Though perhaps the problem might be with the dig command in of itself. There are probably more intuitive and time saving ways to do building period, that don't involve digging room after room. We'll see.

I'm gonna remove myself from the discussion for the moment, mostly to collect my thoughts on it and write out an actually fleshed out idea for this baby's-first-MU package. I'll poke at the Evennia people as suggested earlier.

[Jaunt]

@HelloProject said:

There are probably more intuitive and time saving ways to do building period

Most definitely. I think, ultimately, a fully realized web-based interface for building and scripting and other softcodey things would probably be the best, most intuitive approach for MU*s. Some engines have such things (some older versions of SMAUG, for instance), but most old OLC systems have become out-dated over the years ... as the genre's become more insular and isolated, there's been less motivation for creating and maintaining accessible OLC.

It's still just as important as it was like 20 years ago to bring in new developers, though.

[Sunny]

@Jaunt said:

I think that the prompt idea is interesting. If you could make a prompt system that was optional (for instance, only used if you typed "@dig" by itself), and was designed to actually help teach you how to use the @dig command (by showing you the new sum output for each step, highlighting the additions or some such), then I think you'd be onto something.

One of the games I play on (KD) has a prompt thing set up for creating an event as well as for RP-reports (they're optional), and I have to say it's one of the easiest way to do those things that I've encountered. User friendly, the help is embedded (the script basically explains itself to you), and so on. I think the @dig prompt discussion...it's just a case of designing the prompts right to make it both intuitive AND user friendly. So I'd do something like this:

@Derp said:

@dig Kitchen=Kitchen;K,Out;O

dig

$ Name of the room you're digging?
Kitchen

$ Return Exits?
Yes

$ Name of the return exit? Format is name;alias;alias;alias (Such as Out;o;exit). Please include 'o' and 'out' for exits that lead back in the direction of the city grid.
Living Room;lr;o;out

$ Name of exit that leads to the room from your current location? Format is name;alias;alias;alias
Kitchen;k;kitchen

If you expand on the prompts like that, something like this could be both simple and intuitive. I do also think that the non-prompt version should be available for things.

--

I'll also note that some of the things being discussed are already possible with our current platforms. My game-in-the-works is setup so that all I'm going to have to do is create the news files / other documentation on our wiki in a particular way, and the game is setup so it automagically picks it up from the wiki and sticks it into the news files / help sections without me having to touch the server side of things. The last site I was working on/my social place, my wonderful coder set it up so I could do all the editing on my computer, then push a button on a program we set up and it would load the file right into the game from there.

ETA: That thing I'm talking about above is something I don't think I could live without, these days, so having it being an option in developing platforms is I think kinda a big deal.

[Tyche]

@Derp said:

Think of it like this:

@dig Kitchen=Kitchen;K,Out;O

Under your version:

dig

$ Name of the room you're digging?
...

This reminded of ColdCore which implements both.

   Syntax: @dig <place>
           @dig <leaving way>[|<arriving way>] to <place>

   Syntax: @build

  To use this command simply go to the place you wish to extend, and type @build. It will prompt you for all of the information to build another place connected to your current location.

Of course 'dig' without the sigil might be right out, because that could be an IC command used to dig holes, graves and what not. I don't think it's that big of a deal to provide multiple interfaces.

[il-volpe]

A MU client that detected the type of MU you were on and correctly determined the commands for most ordinary actions and made them into buttons you could click (while still allowing you to enter the command directly if desired) would probably be awesome. It'd turn the learning-to-function-in-MUSH experience from a 'what the fuck do I do at the DOS prompt?! Tell me! Ffffff!!!' experience into a learning-hotkey-combos-for-a-GUI sort of experience.

[Derp]

@il-volpe said:

A MU client that detected the type of MU you were on and correctly determined the commands for most ordinary actions and made them into buttons you could click (while still allowing you to enter the command directly if desired) would probably be awesome. It'd turn the learning-to-function-in-MUSH experience from a 'what the fuck do I do at the DOS prompt?! Tell me! Ffffff!!!' experience into a learning-hotkey-combos-for-a-GUI sort of experience.

How would that work, though? I mean, you can make buttons for every command, sure, but unless you know what goes after the start of the command, it's not that much more useful. You still have to know what each of them does, and when to use them, and what goes after the thing that initiates what you're trying to do.

I mean, there could be a way that it could work. I'm just not sure what use turning the commands into buttons over typing them into the send window is. Can you give an example?

[Griatch]

@il-volpe
This would likely require the explicit collaboration of the MU* server really, together with either a custom web client or a telnet client using an out-of-band protocol like MSDP or GMCP. It's usually done not by identifying available commands but to "skin" the client to a specific game (see Mudlet for an example of such functionality).

@Derp
In principle you could in a web client (or custom client skin) imagine pressing the "get" button and get a pop-up menu of things you could get in the current room. For other commands you could picture the player stepping through a series of dynamically generated pop-up menus (where each choice informs what menu/list appears next) in order to build up the command's arguments. At least if you are not dealing with global objects but only stuff in the same room, it might be quite doable. I'm not sure it would be a better way to handle commands, mind you - or that it's something I would ever do, but it's one way it could work. For having newbies learn/explore commands though, it might be more approachable I guess.
.
Griatch

[il-volpe]

@Derp -- @Griatch answered your question about how it would work.

I would suppose it would, when you connected to the MU the first time, send a bunch of commands until it found the right ones, so it could give you a button for everything you need, poses and pages and all.

It would not be a better way to handle commands at all. It would be slow to use. But right there, on your screen, would be this set of buttons giving you a visual idea of what you can do. As it is now, to play a MU, you need to actually memorize some commands to put into a command prompt, and my guess is, people would rather learn them as if the commands were nifty shortcuts than need to learn them before they can do anything.

@Griatch -- I am sure you're right about the collaboration, skin, etc. I know fuck-all for coding when it really comes down to it.

[WTFE]

When watching people talk about future MU* technology it's like the last 40 years of software research and development never happened.

[SparklesTheClown]

@WTFE said:

When watching people talk about future MU* technology it's like the last 40 years of software research and development never happened.

That's kind of how I feel. It's like, when I think of the possibilities for MUing, I start to wonder if we've just entirely forgotten about literally everything else that could be applied to improve MUing.

[Derp]

See, like... the problem that I'm having with wrapping my head around this is... what sort of 'new advanced things' are we talking about?

It's a MU. It's, fundamentally, text manipulation and basic math. I mean, yes, you have some more advanced options in the form of selecting how text appears and who it goes to, etc, but no matter how advanced and shiny you make it, the fundamental things you need are some way to print entered text, and some way to manipulate numbers.

Some of the suggestions made just seem like adding features simply for the sake of adding features, even if they don't actually improve upon anything. Sort of like this idea of buttons for all the commands. What does that accomplish that your welcome screen on a mush can't? 'Hi player, we assume you're new, here's what you need to get started.'

I mean, think of your most commonly used things. Pose, Say, Emit. The only things they do, literally, is change how the thing sent to the room you're in starts, and of course they can trigger certain side-effects with advanced foo (that no one ever uses). But even if you have a button for all three of those, seriously, how would it even be used? Do you hit the button and then type what you want to send, and hit enter? Do you type what you want to send and then hit the button to do it? Even the 'get' thing earlier, if you know what you're wanting to get, why do you need a button that does it?

Sure, you can throw some fancy things in with all the things we've done in the last few decades. You can watch dice roll across the screen with nifty graphics, and maybe throw some rich text in there (god help us all, it'll be Papyrus and Comic Sans just splattered all over the place...)

Yes, we've made lots of advances, but how advanced does it really need to be to do something that's essentially a glorified skype window with an internal calculator?

[Sunny]

@Derp

I think a lot of work could be done not on the player UI side, but on the game creation and development side. As far as the player side goes, I'm sure there could be improvements, even if I can't really think what it would look like except perhaps taking Simplemu*'s lead and integrating the platform with the client a little more (simplemu* has things like a separate window for WHO if you want it).

There have actually been significant advances in the platform software I most frequently use since I started mushing, at least. New from when I started that make a difference to me as not-a-coder (the advancement on the code side is, I know, also significant):

Communication with external resources
256 color
Realms
Basic softcode packages included with install
idle (not all of them have adopted this yet)

And so on. These things were certainly improvements both on the player side and on the game creation side of things. So this is the sort of "new advanced things" -- you don't really realize you needed something until it's there, and then you wonder how the hell you lived without it.

[SparklesTheClown]

The point isn't to make things more advanced, it's to use advancements in technology to make them -simpler-.

There's something I've often said, for years, not really to do with code or anything, but with, like, I guess nerds? We have this disconnect when it comes to what we know how to do and find simple and easy, and what other people know how to do and find simple and easy.

We're used to certain things, we think, "Well, this is easy to me, so obviously it couldn't possibly be any simpler". I've met people who had trouble figuring out how typing urls into a browser worked. And guess what? It could be easier.

That disconnect from everyone else, where we think, "Why can't they just -do- it, it's so simple!" is reflected in the fact that our hobby has barely evolved from a period where computers were considered almost totally inaccessible to people who weren't hardcore nerds.

It's not a flaw to be so good at things that one finds those things simple, because those things have become a part of your everyday skills. But when thinking of what's simple and what isn't, I think of this on two levels. What's simple for me, and what's simple for someone who has absolutely zero knowledge of the thing I know how to do. I feel like it's a great way to think in order to think of how things can be innovated and simplified.

I'm still working on a proposal for the Evennia people in between writing work that I'm actually getting paid for, so I think I should be able to illustrate what I mean soon.

[Jaunt]

@Derp said:

I mean, think of your most commonly used things. Pose, Say, Emit. The only things they do, literally, is change how the thing sent to the room you're in starts, and of course they can trigger certain side-effects with advanced foo (that no one ever uses). But even if you have a button for all three of those, seriously, how would it even be used? Do you hit the button and then type what you want to send, and hit enter? Do you type what you want to send and then hit the button to do it? Even the 'get' thing earlier, if you know what you're wanting to get, why do you need a button that does it?

I wouldn't create a button for to-room roleplaying tools. I do think that they can be made more intuitive (for instance, by removing the need for the commands themselves and using a symbol like @ or the like to parse, so that the "command" is as close to just writing prose as possible).

More important, I think, is to create rewarding, immersive tutorials to teach players how to use the commands they need to use most frequently. The rest of the gaming world has caught onto this, but our approach to tutorials has been cave-man at best.

As far as 'get' goes, if you wanted to, you could create UI that would allow you to click on an object or character and see a dropdown menu of different ways that you could interact with that object. If there weren't any additional scripts on objects, picking them up COULD be as easy as clicking on them. And clicking on objects to take them is definitely something that all gamers understand.

None of these ideas (besides tutorials) are great for every game, but if you can step back and not make any assumptions on how things should be for your game (in terms of commands and interface), then I think you'll find a lot of little things that could be done to help make them more accessible to new players.