[MUD-Dev] Text Muds vs Graphical Muds

[Sanvean]

On Fri, 21 Jun 2002, Michael Tresca wrote:
> Anderson, David posted on Thursday, June 20, 2002 4:16 PM
 
>> Any other ideas why text muds seem to stop growing at some point?
>> The servers aren't slowing down, it's not like the box can't
>> handle another few hundred people.
 
> Lack. Of.  Vision.
 
<snippage>

As with many things, the more time spent planning, the better. We
came out with a mission statement about two years ago, and every new
staff member signs off on it when they come on. Which means they see
right off the bat that we're serious, that we take pains to act
professionally, and that we put a lot of time (and love) into the
mud.

A mud stops growing when the staff stops having a common vision that
they can all work toward. Armageddon could easily have faltered at a
number of points, but instead it's grown, to the point when the game
of today bears little resemblence to the old version, which was
fraught with callous staff members, embittered players, and a lot of
irresponsibility. By contrast, it's become an active, engaged
community, where both players and staff feel ownership of the game,
and with a standard for RP that I will boldly claim is, if not the
best, surely there in the top group.

The mission statement, for those interested, goes like this:

  Preliminaries

    Armageddon is not a company or corporation; Armageddon is a
    hobby. It's the equivalent of having a huge train set in our
    collective basement, and obsessively going down to tinker with
    it. We want everyone to enjoy being on staff, to feel that
    they're doing things purely because they want to, and in fact
    the primary reward anyone should expect for donating their time
    to a hobby is the enjoyment of the time spent.

    The one responsibility that everyone on staff has, and the thing
    you implicitly agree to when becoming a staff member, is to be
    an active member of the staff community. This means you should
    keep up to date on what is happening, in the form of reading the
    IDB and CDB on a regular basis, and provide information to
    others in the form of feedback on what they're doing, as well as
    sharing what you're up to. People who are not a part of the
    community are not contributing. If you don't enjoy being a part
    of the staff community on Armageddon, then you probably aren't
    going to be in charge of much.

    That said, we'd like to outline what we feel is most important
    to the game, because as Overlords, we think it's vital that our
    vision for the mud be clearly communicated. Armageddon has
    evolved and changed over the ten some years that it's been in
    existence, and it will continue to evolve, change and
    (hopefully) grow.

    Accountability comes in three flavors: accountability to the
    game, to the players and to the other members of the
    staff. Here's how we see each:

    Accountability to the game: To keep working towards the goals of
    game stability, playability and consistency.

      Building: Making items and NPCs that are consistent with the
      current guidelines.

      Building: Keeping abreast of changes and events on the game.

      Building: Taking charge of typos and ideas, fixing and
      verifying them and then making sure they get cleared out of
      the file once they've been verified/approved.

      Coding: Not leaving code half-baked or unfinished.

      Coding: Making sure code is balanced and consistent with the
      current documentation.

      Coding: Spending time on code that will maximize people's
      enjoyment of the game, rather than focusing on code that is so
      specialized or complicated that it may never get used.

      Coding: Taking charge of bugs and making sure that they are
      fixed, tested, and removed from the bugs file when resolved.

      Staff: When posting on the Net, in the form of usenet
      postings, ISCA, or the Armageddon webpage, or emailing
      players, to refrain from flamebait, statements which cast a
      bad light on the game, or insulting other MUDs.

      Quests: Running quests that are consistent with current
      guidelines, which incorporate existing events, and which don't
      collide with things already existing on the game.

    Accountability to the players: Treating players fairly and
    consistently.  Building: Keeping your clans informed as to
    IC/OOC events, and making sure you check bugs/ideas/typos on a
    regular basis to fix things that affect them. If you have to
    take RL leave, make sure your areas are covered so the players
    aren't left in the lurch. Coding: Testing changes thoroughly to
    make sure they don't crash us, and posting what's been done in
    case not everything was tested sufficiently so the crash bug can
    be fixed Coding: Making sure command syntax is (fairly)
    intuitive and more importantly, that command syntax is
    consistent Coding: Making sure new features are sufficiently
    documented in the form of helpfiles, as well as included in
    news, the MOTD and/or the GDB. Documentation: Answering
    questions on the GDB, wishes, account mails, mails to clan
    immortals both informatively, politely, and in a timely
    way. Quests: Running quests which are consistent with current
    documentation. Finishing quests completely, and not scheduling
    events for players and then failing to show. Quests: Treating
    players fairly. This is not to say do away with the karma
    system, but hand out karma or perks to players who have earned
    them. Not because they're a pal in real life, or bought you
    beer. Quests: If a player dies or is harmed as a result of your
    actions, emailing the account with a report on what happened, so
    if the player emails the account about it, their letter can be
    answered. Staff: To be consistent in how things are done. For
    example: Booting the imm port at a consistent time, so the
    players know when to expect it will be down, and when it will be
    back up again. Or setting out guidelines for approving/rejecting
    apps, and letting the players know what those guidelines
    are. Accountability to Staff: Respecting the efforts and time of
    the other staff members.

    Building: Not interfering in another person's area of
    responsibility or doing something that will have a major impact
    on them without checking/letting them know ahead of
    time. Coding: Airing major changes on the IDB ahead of time, and
    asking for input. Not making a major change without some
    consensus on the part of the upper staff. Coding: Documenting
    changes thoroughly and letting people know what's new so they
    can incorporate it in their quests and building. Coding things
    that are useful to other staff members, and making sure there
    are no bugs in the code which create problems for people running
    quests or building. Quests: Keeping each other informed of
    plots, events and other information they might need. Staff:
    Treating each other fairly and consistently, trying to work out
    problems directly, or, in the case of Storytellers and
    Highlords, through someone higher up, should the problem not be
    directly resolvable. Not engaging in backbiting, or discussing
    other staff members with players. Staff: Letting the rest of the
    team know when you will be absent, particularly when there are
    plotlines or projects that are dependent on you. Staff: Adhering
    to the guidelines sent out in the Storyteller and Highlord
    documentation, including the staff contract.

  Priorities:

    The priority list for working in any area of the game, whether
    it's coding, quests or building, are:

      Stability: Increasingly, we're working towards less lag and
      longer uptimes. Being able to use the testport to test
      possible crash bugs will move us even further in this
      direction. 

      Balance: Making sure code and building do not unbalance the
      game. Documentation and building like Halaster's template
      weapons or Krrx's template NPCs assists in this as well.

      Consistency: Adhering to the existing documentation. while
      continuing to expand it. Making code and syntax consistent
      overall. 

      Accountability: As listed in exhaustive detail above.

      G-Factor: Things that make players go 'Gee-whiz, that's cool!' 
      Anything from a small building detail to a slick piece of code
      or an inventive, atmospheric quest.

  Focusing on using/extending what we have:

    Code: The code shouldn't be so specialized. Any spell should be
    usable as a spice, as a poison, as a psi power, as a skill. And
    the other way around. We add new skills, and people want more
    spells, we add more spells, and people want more psi powers. And
    all of them have bugs and issues of game balance. Focus on using
    and extending the functionality of what's there.

      Example: People make requests to see DMPL extended here or
      there, or see fixes in DMPL. This is a prime example since
      they're not asking for a whole new language, just a more
      stable and usable feature in DMPL.

      Example: Checking the bugs file to look for flaws in your own
      code, and making sure they get fixed, so the code is fully
      functional.

      Example: Expanding the light code and adding color values
      while fixing it so the room echoes when someone moves in with
      a light.

      Example: The gith_gear dmpl, which works with existing
      merchant code, rather than against it.

      Example: Having the crafting code often work with forageable
      objects.

      Example: All the additions Morgenes has made to the emote
      code, such as being able to use emotes with objects.
 
  Quests: Quests need to be followed through on. Starting a new
  quest is not a solution to leaving another unfinished. Quests,
  like code, should interact more. Quests should also try to use
  what's there, to expand and amplify the existing world and
  documentation.  Example: Daigon doing Byn travel quests, and
  Keraptis coordinating with BlackMoon raiding quests.  Example:
  Quests which use past events as a basis, such as Radoon's going to
  Mal Krian to find the ruins of the library there. Quests that ask
  players to find an item or NPC that is already in the game, rather
  than specifically built for the occasion. Example: Bhagharva and
  Talley adding to the arena area, as well as the existing code
  there, to create the Gladiator RPTs. Example: The 'quest' where
  the elves & humans fight for territory in the 'rinth. This doesn't
  involve demons, ancient assassin cults, or anything, and the
  players are free to explore it and find out what is going on, they
  can take part, or flee it. Example: Kadius sending people on
  weekly 'quests' to find items for the stock and warehouses. This
  makes them interact with the existing world and existing code to
  get what they need. They feel that there's a benefit to exploring
  and learning the various markets.
 
  Building: There's not as large a need for 500 new items, as there
  is for having the existing database used more. Example: Rotating
  shop merchandise to get old items out into the game.  Example:
  Going through the existing database to fix old items or make sure
  they're flagged correctly. Example: Revamping existing areas, such
  as Krrx did with the Red Desert and the Salt Flats. Example:
  Making the crafting code work with as many existing objects as
  possible, rather than building entire new sets. Example: Camps and
  villages. The wagon code wasn't intended to be used this way, but
  it is an excellent extension of existing code. Example:
  Tents. Again, an imaginative, interesting extension of the wagon
  code which fulfills a player need. Example: Lizards/Birds that are
  'alive' that people use as pets. Rather than coding it to allow
  NPCs to exist within characters.

  Summary: We've always been about quality over quantity; this is
  only backing up that ideal.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev