Posts made by faraday

@Ganymede said in Game Stagnancy and Activity:

The combat code is unforgiving. And we all had a blast, even though one of us nearly died a horrible death.

I'll emerge from lurking briefly to point out for those who don't play the game that you can't die unless you choose to. Worst that happens is you get taken out of action for a week or so.

@Tez said in Game Stagnancy and Activity:

How do those smaller plots run within the shell of the -- umm, I'll call it a plot arc -- really impact the word?

The trick, as @DownWithOPP alluded to, is to have an open-ended plot arc. You have to be willing to let the PCs steer the course (within reason). Like the POW camp rescue he mentioned - that wasn't my idea. One of the PCs wanted his backstory to be "rescued from a POW camp" and worked with some other players to lay the groundwork. All I did was give them opportunities to have RP around that plotline through a mix of staff-run and player-run plots.

There was another little one-off event @DownWithOPP did where the Cylons pretended to be friendlies and ambushed the PCs. A week or two after that, I built on that idea by having another event where the Cylons again tried a similar trick - this time resulting in a "friendly fire" incident that spurred a lot of RP.

You don't have to let someone blow up the grid every week for them to shape the story.

@Tempest said in Game Stagnancy and Activity:

Who is going to be taking the time out to do this?

A PC running an event and posting the log is incentivized by luck points and my heartfelt gratitude. If you go the extra mile and post to the Scuttlebutt board (which is basically the "what's happened ICly" BBS), bonus. If not, I will. We have 20-some active players and I can keep up with the activity all by myself. It's work, sure, but it's not insurmountable.

I think that keeping players in the loop is critical to spurring RP beyond the event. We have levels of that:

• Scuttlebutt BBS (for up-to-date summaries on what's happening.)
• "Story So Far" cliff notes wiki page (for new players who understandably don't want to read seventy billion bbposts.)
• RP Logs (for folks who want the gory details. I'm pretty compulsive about posting logs for the missions.)

On Babylon 5 and BSG:Pacifica we had a similar thing to the Scuttlebutt board for IC news articles. Those things help a lot with recognition ("hey I made the news!") and staying connected.

I think that the game theme helps a lot with stagnancy. On the BSG games it's pretty much set up so there is constant action - that's the whole point. On Sweetwater (my western game) we did pretty well for awhile when the Range War plot was going on and there were constant plot developments around that. Once that metaplot ended, there was nothing cohesive to spur things along and the game went off the rails.

@Groth Yes, so by all means let's do nothing at all to make things as good as they can be given the limitations of the technology. I've said my peace. I'm out.

@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?

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

@faraday All of the things you responded to are a problem with /documentation/ not coding. You can change the documentation, get people pointed in the right direction so they know of the + commands and then... guess what? Your whole UX 101 thing is solved.

Done.

It's all about presentation and documentation rather than what the coded command /is/.

Actually, documentation is widely regarded as the very last line of defense for UX. If your UX is so poor that you require the documentation for basic operations, you've failed.

Personally I'm quite comfortable and familiar with MVC, but most MU coders are hobbyists. Simplicity is more important that design patterns IMHO.

Compare having everything in a single command handler:

  class FooCmd
      def handle
           parse the input
           do something
           emit something (usually to the enactor)
      end
  end

Versus having a model, a controller, and multiple views. Self-contained is way simpler.

And that doesn't even address having to learn all the web technologies now (javascript, rest API, whatever) on top of the base MU code.

Someday I will do a completely web-based game, but I have decided that trying to support both web and telnet interfaces runs contrary to the design goals of Ares. If folks want to do that with Evennia, best of luck to them.

@Sparks In principle I agree that that's the "correct" way to do it. I didn't go that route personally for Ares because I have no intention of supporting both a web UI and an in-game UI for most stuff. Chargen is a notable exception. The complexity of supporting two independent views and making sure everything melds together is just... no.

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

I've yet to see anyone adequately simplify mail in a way that justified having to learn entirely different annoying mail code rather than just keeping annoying mail code I actually know how to use.

My mail system doesn't simplify any of the basic mail structure, but it included a variety of features: a meld of quickmail and composition, enhanced mailing lists, better mail sorting and retraction, mail archive, automatic 'sent mail', quasi-threaded replies, and - most importantly from my code's perspective - the ability to send mail from a function to better integrate with the other coded systems.

Now maybe some or all of this exists in Penn now but at the time it didn't. It's just another example of what I keep talking about -- the most basic use cases are identical to the built-in systems to make the transition easier, but it provides additional features beyond them. Now maybe that's not enough value for you - that's your prerogative. But it is for me, and it's my code, so...

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

Unless you want to make it so the who list can be sortable by the person checking it i fail to see how having the same information presented in two different ways is a bad thing.

Those are valid reasons for expanding the functionality of the 'who' command, not for having two obscurely different versions of it. But that's just IMHO. If you're happy with the status quo, then there's no reason to change anything. Some of us aren't, though.

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

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.

In my experience, that is quite simply untrue. Just look at how many players have successfully transitioned over to Arx (using Evennia) or BSGU (using Ares). I've had a bunch of players on Ares who don't even realize they're playing a different game server. They think it's just some kind of customized PennMUSH. It is absolutely possible to preserve 90% of the experience a player is used to while still expanding and simplifying that experience. It's called backwards compatibility and it's really not rocket science.

As for why more people aren't using them, there are a variety of reasons for that, not the least of which is that both are still in development.

@Groth Because the base game engine comes with a lot of basic functionality that you probably won't ever touch. Unless you really have some overwhelming hankering for a custom page command, or pose commands, or movement commands, or what-have-you. That doesn't mean you need to invent a whole other command notation for the things you do want to customize/change. But if you don't believe me, just stick with Penn/MUX and keep using + commands. Really, it makes no matter to me.

@Groth If you want to sacrifice usability for your players in order to support a hypothetical MU* scraper or to avoid coding extra stuff into +who for admins, that's entirely your prerogative. But I will agree with @WTFE here and say: That doesn't mean it's good UX.

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

So how do you now distinguish between the default mail which people expect to be there from your super special mail you wrote for this game in particular?

You don't need to. Really, you don't. If you want to provide good UX for your players, then you will make the basic mail commands on your super-special custom mail program work the same as the built-in mail. Then it doesn't matter what additional features you provide.

As long as 'who' tells them who's online, they really don't care what it looks like. There's no reason to separate WHO or +who (other than the aforementioned historical reasons).

@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.

@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.

@WTFE If we're starting from scratch, there's no need for command prefixes at all. Ares doesn't use them and it works just fine.

For the existing servers, though, there are real limitations based on the hardcode/softcode divide.

Just one small example: My Penn softcoded +help is searchable, does partial command matches, the help files are editable in-game, and I have an API function for installing/uninstalling help files that supports my install manager. There's no way to do any of that with the hardcoded 'help' system (without forking the hardcode). Conversely, I don't think it's beneficial to clutter up +help with the 5 bazillion built-in help entries for MU functions and useless commands just to unify the systems. I'm not even sure you can disable built-in help and have a softcoded 'help' command. (though maybe you can; it's been awhile)

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.

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

This by itself isn't particularly a syntax issue (though I still think that these plus signs and slashes need to be burned with fire). But the fact that you need two separate commands to join combat, plus a third command to leave combat that you constantly forgot to even use, so you'd be trying to join a combat situation with someone else and you'd be like "Wtf is even wrong". Then you'd have to go and find the room you were in when you started combat to get out of it, if I recall correctly, some crazy shit like that. Then once you do that you can finally go back and finally enter combat with the person you planned to.

See that's a good example. But I can make a counter-example. FS3 combat has separate commands for starting, joining and leaving combat but there's a very specific reason for that.

It enables a GM (who is usually the one who starts combat) to set up the combat with NPCs and everything without spamming the other players, then join them to it later. Combat doesn't auto-stop when the last badguy is defeated because often you'll do a second or third wave of combatants and it would be annoying for everyone to have to re-join afterward.

Which brings us to the #1 rule of UX: Know your audience. Know what they're trying to accomplish, what their pre-conceptions and knowledge is, and then make the simplest possible thing that meets their needs. This is going to vary from game to game.

@Rook Yeah. Although if you really want to get the point across, the mock example also needs to answer the questions: "But what if those modifiers are important" and "But what if those modifiers can have spaces in them"? Because I think answering 'yes' to both of those questions leads you directly to the syntax we already have in the vast majority of cases.

@HelloProject Well I don't play WoD either so those examples don't matter much to me anyway. But I think when you make a thread with the vague assertions in the vein of "MUD coders rule, MUSH coders drool" and then fail to provide any specific, actionable examples of how you think things could/should be improved, it kinda undermines your point quite a bit.

@HelloProject FWIW, I don't disagree with your general point that MUSH UX can be improved. What I'm having trouble with is how you think it should be improved.

You've mentioned macros - okay, @Thenomain says his code has them, Ares has them. I don't think anyone disagrees about macros being useful.

You've mentioned simplifying rolls with abstracting commands - okay, but various people have explained why that's a conscious design choice in all the examples you've cited. Either for situational flexibility (i.e. not having to code up everything under the sun) or for copyright reasons (not being able to completely replace the rulebooks).

You've mentioned systems being different on different games (like +myjobs) but, well, frankly that's just never going to change. With the MU community fragmented as it is, you can't expect every game to have the same command set.

You've mentioned "complicated syntax" but the examples cited (rolls, mail) you don't seem to have a problem with specifically. So... I'm just really not sure what you're talking about there.

We've talked about softcode/hardcode commands and prefixes, but until you replace the old platforms, there's nothing to be done about that.

What's left?

@Rook TGG did it too. But to be fair - I think these systems would be what is being described as "complex" here. Because yeah, they take a lot into account. You can combat/attack troll but you can also combat/attack Troll=Bob/called:head,burst to have the troll fire a burst at Bob's head. Complicated features are complicated, yo.