Posts made by Groth

I personally find attempts to use English grammar-like syntax in CLI commands only make them even more hard to remember and type in properly.

@HelloProject

The basic @dig command in Pennmush works like this

@dig Kitchen

This command will create a new room named 'Kitchen'. You will be informed what the dbref of this room is.

@dig Kitchen=Kitchen <N>;n;north;kitchen;k

This will create the room as above, and also open an exit leading to it named "Kitchen <N>" with the aliases n, north, kitchen and k. It will NOT create an exit coming back from the Kitchen room.

@dig Kitchen=Kitchen <N>;n;north;kitchen;k, Out <S>;s;south;out;o

This will do just the same as the above, except it will also create an exit named "Out <S>" with the aliases s, south, out and o coming back from the kitchen to whatever room you are currently in.

I honestly can't think of a basic digging command that is simpler then @dig.

@HelloProject said:

The average MUSH that doesn't work based on email apps, often involve using a bunch of different commands and having to look at documentation, because often it's not entirely clear how to use the commands.

I'm not saying that one is better than the other, but MUD chargens are usually way simpler than MUSH chargens. They practically hold your damned hand through the entire process.

Keep in mind the main reason most MUSH chargen is complicated is because they're close adoptions of TT RPG systems which were never designed to be used that way.

@HelloProject said:

There's absolutely no reason that one shouldn't be able to quickly build their grid and theme without having to sit down and learn a bunch of code first, soft or otherwise. And no, hosting a server yourself isn't going to be perfect, but this is -exactly- how Byond works and I already have an idea of the pitfalls of players hosting a game on their own computer.

I don't think it's possible to make digging any easier then it already is in most MU* while still using a CLI interface. There are all sorts of benefits that could be realized by creating a system with a graphical interface instead but that's a huge undertaking.

@HelloProject said:

edit: Byond Tabletop allowed you to customize a sheet for people to use, with a shitty version of HTML. You could create different rooms and stuff. And rather than paying for server space, you simply hosted the server on your own computer.

There has never (not even in the dawn of internet) existed a technical restriction that required you to pay for server hosting rather then hosting it yourself. The reason to purchase hosting rather then host yourself have always been the same.

1. It's usually cheaper to purchase a hosting service then pay the electricity bill of keeping a computer on 24/7.
2. It's hard to maintain a good service availability at home between power outages, network disruptions etc.

Minecraft is a really good illustration here. It's utterly trivial to host your own minecraft instance however the virtual hosting providers are ungodly popular because they're really cheap and really easy to use with one-click installs for all common configurations.

The reason you're not going to see 'Babys first MU*' is because unlike Minecraft, you can't really start a MU* by just starting the server configuration of your choice and press 'Go'. After you've put your server online there is a metric fuckton of work awaiting you in making that server into an actual game anyone would want to participate in in digging a grid, writing a rule-set, writing a theme etc etc.

And if you're not going to use a grid and custom built-in rules, it's hard to justify using MU* software over just IRC or Skype.

@surreality said:

There are also usually limits to the kind of storylines players are permitted to run, vs. what storylines only staff can run. This usually has to do with very high-powered antagonists or metaplot (the larger actions at work in the world that are staff-directed, and proceed over a very long period of time).

A number of players never get involved in plots at all. They're more there for the 'improv' aspect of character immersion.

The hard part for MUSH's in my experience has always been the question of world coherency. How do you ensure that all the players feel like they're taking part of the same world even though they all play at different times and with different people?

Some MUSH's like the Exalted MUSH have traditionally taken the approach that they don't particularly worry about it, letting players run almost any plot they want and hand-waving most inconsistencies. Other MUSHes like RfK put a high priority on consistency and sharply limit what sort of plots can be run without the involvement of Staff. I've yet to come across a great solution to give players wide freedoms while making sure that the world stays coherent.

@HelloProject said:

Really, the challenge with drawing players into MUing is actually showing what the benefit of doing it would be to begin with. I guarantee that you could go to some random forum RP or IRC RP and explain MUing, and they'll say, "Well I can do that anyway, why should I care about this?"

MUSH RP is essentially IRC RP with better built-in support for character descriptions, room navigations, room descriptions etc etc. I'm not aware of any IRC based RP communities of significant size however. Things like IRC/Skype is used more for online TT style roleplay which has all sorts of peculiarities of its own.

@Ganymede said:

If you say so. I don't need a well-written policy -- or any policy -- to alert me when a staff member is unfair. All that matters is what I think is fair, not what that policy may tell me is fair.

Alight. In the case of RfK specifically, Shavalyoth founded the game after having bad experiences with Staff on other games with more loose policies and decided to make her own game with clear policies to prevent what had happened in those other games. These included things like never staffing while drunk, never spying on the players with DARK, ensuring that the NPC's play by the rules and a commitment to a restorative system of justice.

Like @jaunt Shavalyoth originally decided that staff shouldn't play PC's at all and she herself never played any PC, however beyond her coder she didn't manage to get anyone else to help out as staff as they all wanted to keep playing so she compromised. As RfK was always intended to be a fairly PvP centric game the policy was designed to make Staff PC's be non-threatening to the rest of the PCs and this was iterated on a number of times.

Overall, my experience was that her policies were very successful in building trust. Not by the sheer fact they were written down but rather by the fact she unfailingly kept true to the promises she made to the playerbase and that the people she brought on to help her agreed to do the same thing. If those policies hadn't been written down I think it would have been harder for her to build that trust and harder to ensure that the members of staff she brought in would stay true to her vision.

@Ganymede said:

That's not what I was getting at. I understand this. Judges should do this voluntarily, but do so in obvious cases because their ethical code can be enforced against them. On a MU*, if staff don't follow or enforce their policies, the policy is pointless.

I've been around the block for a long time, and I don't believe any code or set of policies will make me trust staff more or less than the reputations they have.

On a MU* if Staff don't follow or enforce their policies, the policy isn't worthless. The fact the policy exists and they ignore it tells you that the staff of that game are untrustworthy which is valuable information to have, especially if you can get it before you've deeply entrenched yourself in that particular game.

In the absence of a well written policy it's very hard to tell when a staff member is being fair and when they're just making things up as they go along.

@Ganymede said:

You cannot reasonably compare the situation to judges and their family members. Judges can be impeached and censured in a variety of meaningful ways. Staff cannot, other than removing them.

Character is what is most important. And vigilance by administrators..

Note how even though Judges can be impeached and censured, they are still expected to recuse themselves from cases where there might exist appearances of impropriety. Good staff policy is about the same thing. It's extremely rare in my experience for members of staff to actually cheat but by removing obvious conflicts of interests off the table entirely you make everyone feel more comfortable.

@Ganymede said:

I don't think the issues are problematic if you have good staff. In fact, none of these scenarios of doom-and-gloom arise if the staff can be trusted with the power they have.

As an administrator, if you don't trust your staff, why are they staff?

I understand the concern, but I, like many ex-staff, despise setting policies based on the lowest-common denominator's behavior.

To me the problem is not if I trust staff or not, the problem is if the players trust staff. Staff trust is one of the most valuable commodities a game has and giving the players various guarantees to protect them against bad behaviours they might have encountered in other games is one way to earn that trust.

It's the same reason that you don't want a judge to rule on their family members. If they're a good judge they'll judge fairly either way, but even if they do it'll look bad and damage the trust in the system.

@Jaunt said:

I agree in regards to player experience. We use a toolset that lets us snoop players to see their real-time input/output from their perspective. We use this to keep up on what folks are doing, but also to view gameplay and experience through their eyes.

That's probably not something I'd see go over well in a MUSH. After all quite a lot of the player input is all sorts of rather personal communication.

@Jaunt said:

Loading superior equipment for your character to use or sell.
Changing your character's stat/skill sheets.
Spying on other PCs that are in IC opposition to yours, to give you a meta-gaming advantage.

Most of those are concerns on many MUSHes as well. On our game every member of staff had access to every character sheet, every faction board, every player request etc, that makes any sort of conflict with a staff PC ludicrously one-sided before you even take into account deliberate cheating.

@Jaunt said:

2. Because they are so invested in their player characters, and they have the ability to do so, they cheat to get ahead. Cheating has always been a huge problem with MU*s, because there is an important trust-based relationship between player and admin. When that trust is destroyed, it very often ends up in an eventual player exodus, and it's really difficult to re-build.

That's why staff on my games don't play PCs. We test PCs for gameplay purposes, and we observe others' play, and we GM --- but that's something that I always feel strongly about. Even the perception of cheating (even when it might not be true) can ruin the trust between players and administrators in other MU* sub-genres.

The compromise that we decided on in our Requiem2.0 MUSH was that we would allow Staff to play PC's but those PC's would never be able to 'get ahead' by making it against the rules of the game for Staff PC's to hold any position of influence beyond place-holder. I think this worked reasonably well though in practise the most active staff barely played their PC's due to being busy staffing, still the option to play was nice.

There does exist one notable advantage to having staff members who actively play the game and that is that they experience first hand how the game feels from the player perspective. As Staff it's easy to lose touch with what the actual game is like.

@mietze said:

It can be a bit of a balance though. My ideal is someone who has a PC with flaws, who RPs them, but who is /also/ capable of give and take and noticing/playing off others' flaws too. Because there are some people who are so in love with their broken PC that sometimes they become very self centered as far as needing that to be the focus of all scenes you have with them. (The If Only People Bothered to Unwrap My Awesome PC but Instead They're Bothering Me With Their Own Stuff people--I bet everyone has experienced that too.)

This is actually what I find the most enjoyable with MU* RP, the interactivity, having your characters learn about others, having others learn about your character, having relationships develop etc.

One of my most amazing experiences was when the person I RP'd with ICly commented on a minor thing from one of my poses more then a week previously. I felt completely floored by the fact someone had actually noticed and remembered such a minute detail.

I'm not particularly good at making deep and flawed characters, however I try to make characters that are interested in others and hopefully fun to interact with.

So looking through the Evennia documentation it seems to support most things that builders would expect out of softcode. The main thing it does not support is the ability to define commands however in my experience builders do not usually need or want to define commands.

The bigger issue I see is that the command library looks rather sparse. For instance their example smile command looks like this

from evennia import Command

class CmdSmile(Command):
    """
    A smile command

    Usage: 
      smile [at] [<someone>]
      grin [at] [<someone>] 

    Smiles to someone in your vicinity or to the room
    in general.

    (This initial string (the __doc__ string)
    is also used to auto-generate the help 
    for this command)
    """ 

    key = "smile"
    aliases = ["smile at", "grin", "grin at"] 
    locks = "cmd:all()"
    help_category = "General"

    def parse(self):
        "Very trivial parser" 
        self.target = self.args.strip() 

    def func(self):
        "This actually does things"
        caller = self.caller
        if not self.target or self.target == "here":
            string = "%s smiles." % caller.name
            caller.location.msg_contents(string, exclude=caller)
            caller.msg("You smile.")
        else:
            target = caller.search(self.target)
            if not target: 
                # caller.search handles error messages
                return
            string = "%s smiles to you." % caller.name
            target.msg(string)
            string = "You smile to %s." % target.name
            caller.msg(string)
            string = "%s smiles to %s." % (caller.name, target.name)           
            caller.location.msg_contents(string, exclude=[caller,target])

That is not a reasonable way for such a simple function to be written. One of the few strengths of MUSHcode is that it has very powerful and easy to use parsers built in and all the relevant variables like the caller, target, arguments etc are already pre-stored into default substitutions variables.

@mietze said:

I think that's why there was a Rumors account for RfK wiki, that everyone knew the password to. That way it wasn't obvious to wikistalkers, but the players who posted the rumors had to claim them via beat reporting so that staff knew, or else they would be removed.

Yes, the shared account helped somewhat in preventing mostly unintentional IC/OOC crossovers when it comes to rumours and by having them logged and investigatable it meant that there was always IC accountability to be had.

What started to bother me however was that while we had an IC process to remove rumours, mainly intended to allow characters to get rid of things that were in some way harmful, in the last couple of months it became a trend to try to scrub their characters wikis of the most innocuous stuff and I couldn't understand why.

The purpose of rumours on RfK was to provide RP hooks and a way for players to learn more about what's been happening IC lately. If everything that's not self-promoting is scrubbed away, what's the fun in reading that?

@mietze said:

I think lying OOC is pretty much almost always problematic. Unfortunately some people cross the two. They can't accept that a nasty or swindling PC could be played by an above board/non-cheating player. Or that someone who plays a PC who is one of their buddies has in fact been pretty nasty and destructive OOC, and may have kind of been using them to that end.

The most stupid example of OOC lying I've come across yet was when I transitioned from Player to Staff on RfK. In the weeks before new years I had been talking with the people running the game at the time that I was planning to have my character go out in a blaze of glory of some kind and once my character was gone I'd like to help them out running the game.

The original plan was for one of the staffers to run a plot for me in which my character died, however what I hadn't expected was that a certain IC personality conflict would blow up in such a way that my character would end up PK'ng @Alzie's character in the middle of Elysium. What then followed was a clusterfuck of a scene where 30+ people wanted to get involved and by 3am my time (CET) the my character was declared de-facto torpored and I went to sleep as my input was no longer required.

The next day I ask one of the people involved if they know what happened to my character after I went to sleep and they tell me 'No, I have no idea'. Afterwards I learn their character shot mine with a crossbow and transported the body away. It wasn't the best start of our Staff/Player relationship.

@Thenomain said:

Without an in-game language, Evennia is a Mudlike and not a Mushlike. It's a Python Mudlike instead of a C Mudlike, which should make it somewhat more accessible to non-coders, but that it's not Mushlike it should make it a hell of a lot more accessible to coders.

Volund and I did kick around some thoughts about this. IMO, until Evennia has an in-game code framework, it's going to be harder to appeal to us Mushers. ("Harder" not meant to imply "no way in hell" but something we'll have to consider in the negative column.)

I say this before diving into the new Mu* platform, but the people I am the most concerned for are the builders, who are not coders but do a lot of code-like, meta-game things. We shall see.

Honestly I've always viewed softcode as a bug rather then a feature. Why would you ever want to insert code line by line through a chat client?

If you're creating a new environment from scratch, why not create a proper interface for building with contextual commands, the ability to preview results before pushing them onto the game etc.

My favoured approach in those circumstances is 'Trust but verify'. In practise this means giving players a wide freedom to do handle things on their own while making sure that everything important is logged somewhere so a staffer can investigate if needed.

@Ganymede said:

I'd gladly play on an Exalted game if I had a better handle on the rules. They seem overly complex to me.

So, the thing about Exalted, atleast 2e. Is that the rules themselves are really simple, it's just your basic storyteller D10 Attribute+Skill stuff. Playing an Exalted mortal is no more complicated then playing a GMC mortal.

Where it gets complicated is the same place where nWoD Mage gets complicated, in that there are literally thousands of printed powers with all sorts of unique interactions and only the most insane of players and GM's actually keep track of them all. However as a player, you don't actually need to learn all the powers, just get one of the resident crazies to help you find the ones you want and you just need to know those.

Personally I'm just entirely burned out on Exalted 2e and might take a look if 3e turns out to be playable.

Yes, PvP mainly comes down to what sort of setting you're playing. For instance I think that trying to play Vampire on a MU* without embracing the concept of player conflict is a rather silly endeavour as one of the most central themes of Vampire is conflict with other Vampires however in other settings there may be fundamental concepts of cooperation that makes direct character conflicts out of place.

However I strongly believe that PvP in RPG's only makes sense if you're trying to tell a good story with conflict, it shouldn't be done in an attempt to 'win'.

@Jaunt said:

Please, tell me what the expected standard of behavior customary to the locale is for MSB. You've said this a couple of times, but without more specificity, it's not helpful to me.

The best way to learn is to read some of the threads that aren't about OR. This thread is fun
http://musoapbox.net/topic/381/fallcoast?page=1