MUD Administration

Writing a vision statement/core values.

One of my goals is to have at least a working, semi-intelligent vision statement for my mud project before writing a formal design document or taking on any subordinate staff. It will still be a while before I'm ready to do either of those things, which is fortunate, because I suck at writing vision statements -- most people do, IMO.

I mean, it wouldn't be difficult to replicate the wishy-washy, feel-good crap that hangs on the walls of so many businesses, but I want a good vision statement that will actually mean something to the staff and be more relevant to my mud than to any other organization.

There must, of course, be some core values that are in common to all viable organizations, businesses, games, muds, etc. But which of those are important enough to be in the vision statement of any particular mud?

Next, when it comes to core values specific to a particular mud, it can be difficult to decide what values should truly be held throughout the life of the mud, and which better fit a temporary strategy or mission statement than a vision statement. Do you have any tips for detecting when you are crossing that line? Also, what topics can be considered safer ground in this regard, and what topics should be avoided for being too volatile?

Final question: when writing your Big Hairy Goal -- what my instructors called that short, concise statement of where your organization will be in X number of years -- what do you think is a reasonable substitute for 'X' when it comes specifically to muds (or types of muds, if you think that is more applicable)?

Here's what ours looks like, in case that's helpful to you. This was written about 5 years ago, so I'm noticing it needs updating here and there, but you get the picture. Unfortunately, it's formatted in a way that doesn't translate well.

Quote:

Originally Posted by

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 immortal and coders boards 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:
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 (namedremoved) 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.