From the NannyMUD documentation

LAST CHANGE

2001-10-06

RULES

NAME
        guilds - rules on guilds


DESCRIPTION
	Your guild must not have lower NP requirements to advance to
	new levels; You must use the functions in /obj/util/guildd.

	The guild must be documented, and the docs must be placed in the file
	/guilds/DOC/. Features not documented are
	illegal. Changes, powers etc. must be approved before being added to
	the game. The approval is handled by the guild coordinators of the
	admin. The approval is written in
	/guilds/permissions/.per. The guild doc is secret. Nobody
	but the guildhead(s) and the admin should have access to exact info
	regarding the guild.

	The guild itself must have all files placed under
	/guilds/ to ease maintenance and future changes in
	ownership. This will also facilitate the existence of more than one
	guild owner.

	There should also be a file called /guilds//OWNERS. In
	that file must be specified who owns the guild, and what people
	creates what for the guild. This file must only be changed by the
	guild coordinator.

	Every guild should have a WWW-page. No new guilds will be allowed to
	open without one. Due to patent problems, the WWW page cannot have
	GIF images.


	GUILD DOC

	When you create the guild docs, you have to think of some things.
        1) Split the doc up into several smaller parts. One for the back-
           ground, one for the powers and so on.
        2) When you're describing powers and spells etc, include
           minimum, maximum and average damage/whatever, as well as the
	   formula that generates it.
        3) Describe each subject in one place. For example, describe
           all drawbacks under the headline "drawbacks" etc.
	When the doc has been approved, you should make one file out of it
	and call it GUILD_ and it should be put in
	/guilds/DOC/. You should keep a copy in /guilds//doc/
	which should be updated whenever something has been changed.

	There is an example on how a finished guild doc may look like, called
	GUILD_generics.


	DESIGN

	There are design rules and guidelines for guilds in
	/doc/wiz/guilds/design.  The other files in that dir might also be of
	interest.


	GUILDOBJECT

	The guild object is what marks the player as a member of the
	guild. It need not be visible, but it must have an id
	"guild_mark". It must be autoloading and thus have no weight nor be
	possible to drop.  In addition, the guildobject should have the
	following functions:
	query_guild()	        Returning just the guildname in
				lowercase. e.g. "monk" 
	query_guild_name()	Returning the full name of the guild,
				e.g. "The holy monk order" 



	JOINING

	When a mortal joins a guild, the guild must check if the mortal
	already is a member of some other guild. If so, the player must not
	be allowed to join.  The environmental variable GUILD should also be
	set to the name of the guild. If the player isn't a member of any
	guild, then it has been set to 0. When joining, the mortal must be
	given the guild object.  The object must be possible to clone for the
	admin, and the same goes for all objects that has anything to do with
	the guild.


	LEAVING THE GUILD

	The guild must be possible to leave. There might be a punishment for
	the mortals leaving, but be sure that they know about the price
	before they join. The punishment must not involve the players stats
	or money. The environmental variable GUILD should be set to '0'
	(zero).


	BALANCE

	A guild commonly confers advantages upon the members. There must also
	be disadvantages compensating them. This does not mean that different
	guilds should have the same abilities and/or powers. The guild
	coordinators will compare new guilds to existing ones to keep the
	inflation under control.


	TITLES

	The guild may have its own titles for different levels and sexes. The
	title, when viewed, must start with the name of the guild member. No
	two guilds are allowed to have the same titles, not even subsets.


	EVALUATION

	It is impossible to know beforehand what impact the guild will have
	on the game when it is in full swing with experienced players at all
	levels including the highest. Therefore, the guild will be evaluated
	after a while, and quite possible adjustions have to be made. Don't
	be surprised by this. Instead, keep track of early warning signs, and
	consider what changes are needed.


	ADVANTAGES

	The guild may have a chat-line. Usually, there are some rooms that
	can only be accessed by guild members. If you have a pub in this
	closed area, it will be considered as one of the advantages. Talk to
	the guild coordinator to be sure your guild is unique in its powers.


	DISADVANTAGES

	Talk to the guild coordinator to find out what is considered to be
	disadvantages. To shorten the discussions, here are some things not
	considered as disadvantages:
	* Guild restricted to PK/non-PK.
	* Hard to join the guild.
	* Long or difficult way to the guild.
	* Limits on alignments to advance levels and/or stats



	BUILDING A GUILD

	The first thing to do is to decide the "feel" and "theme" of the
	guild. Then you specify the powers and the drawbacks for the
	guild. Explain how they fit into your guild. Compile this information
	into a guild documentation. Before you write a single line of code,
	read through the help files in /doc/wiz/guilds/. Especially pay
	attention to the file "design". That file contains RULES for how
	guilds are to be designed, as well as hints to help with the design,
	so it is important you're aware of them from the start.

	Let the guild coordinators have a look at it. They will tell you what
	is OK and what is not, based on the game, existing powers of other
	guilds, the powers in your guild etc.

	Write the guild and documentation with details on how things
	work. Talk to the guild coordinators to get the final version
	approved. The docs will then be placed in /guilds/doc/

	If you want the guildmembers to start in a certain place, use the
	environmental variable "START". See "man setenv" for further info.



	GUILD POWERS

	The guild powers should be in line with the mortals guild level
	rather than the player level. This could be accomplished by not
	adding the powers before a certain level has been reached. The powers
	could also start weak and get stronger as the mortal advance in the
	guild.

	A commonly desired guild power is 'teleport to guild'. This will only
	be approved if backed up by very very good reasons. It must cost at
	least 30 sp.  Talk to the guild coordinator for more
	information. Also, have a look at spells.r

	Healing spells (or abilities) also seem to be in demand. Make them
	cost; no healing should be free. Read more in the 'healing' and
	'spells' sections. Spend some time considering if healing is really
	part of the guild's theme.


	ADVANCING LEVEL

	The functions to advance levels and stats can be found in
        /obj/util/guildd. You must use these.


	WIZARDS IN THE GUILD

	You are not in any way forced to let wizards join your guild. If you
	don't want a certain wizard, or maybe even any wizard, in your guild,
	then that person has no rights whatsoever to be in your guild.

	Wizards shouldn't be given guild advantages and disadvantages when
	they log on. However, there should be a (patchable or not is up to
	you) function called "add_guild_powers()" in the guild-object which
	will add the afore-mentioned ads and disads.


	GUILD OWNER

	The guild owner has to have coding experience. Preferrably a well
	written area somewhere in NannyMud. The owner of the guild may assign
	.acl-rights to assistant guildmasters, but only to those who do
	actual coding for the guild. When the assistant isn't active anymore,
	his .acl-rights should be withdrawn. There should be a _very_ limited
	number of assistants.  Retired guildowners may be given "honorary"
	LURX access.



	HELP FILES

	Guilds generally provide help one way or another; how to use the
	guild line, how to join, how to leave, how to use powers, etc. This
	help should be made available to mortals using the ihelp system, and
	be linked in at a suitable place in the ihelp structure. 'man ihelp'
	for more information. The purpose of this is to have all help
	available to mortals via one single command, namely the (quite
	intuitive) 'help'. Dynamic help pages can also be added into the
	ihelp structure if that is wished for.


	MAKING YOUR OWN CHAT LINE

	A modern chat-line consists of a room with statues of the
	participants on the line. This concept enables the line to use much
	of the magic in the driver as well as features of the soul. The
	command to use the line should relate to the guildtheme and
	preferrably be at least two characters long. Also, it should not
	exist for another guild or another command.

	Read the documentation on the chat-line; it's easy to install and
	use. Do 'man line' for more information.


	LINE RULES

	Guilds can have whatever cost the master wants, for example 0SP.
	Traditionally, 3SP has been used for sendto.