INFO
	quality - what quality is

DESCRIPTION

	This document deals with the elusive topic 'quality'. It is no easy
	thing, neither in concept nor in implementation. If the subject of
	what quality consists of is presented to two different persons, their
	answers will in all certainty differ. This document, however, presents
	the view of the NannyMUD admin. 


	1.	What is this thing called quality?
	According to the Webster Dictionary, there are several meanings of the
	word, of which but a few are 'degree of excellence', 'superiority in
	kind' and 'a distinguishing attribute'. When dealing with creations in
	NannyMUD (areas especially), there are basically two parts to the
	quality: code quality and design quality. Those should both work to
	make the game fun and enjoyable while still keeping it challenging.

	1.1	Design quality.
	It is a good idea to designe an area rather than just write it. Doing
	so helps you and the admin to find a spot for the area (even better is
	to design for a special spot), helps you plan ahead and see what is
	needed. Here are a few things to think about:

	+ Document your design! Doing so helps everyone, including you and the
	  admin.

	+ The area should be within the limits of the rules. Exceptions should
	  be noted in your permission file. Remember that too many overly good
	  things will remove the challenging aspect of the game.

	+ The area should be coherent. Ice dragons in hell, underwater killer
	  tomatoes and pie-throwing clowns that instantly kills its opponents,
	  sand deserts in the middle of rain forests etc. are possible things
	  to avoid. Of course an area can have several parts that differ
	  rather much, but that is another matter.

	+ The area should have some detail and at least some of the things
	  mentioned in the long desription of a location should be possible to
	  examine. Some people uses descriptions on everything, in many layers,
	  even including implicit things like the sky, walls etc. You can do
	  that if you feel like it, but you don't have to.

	+ Many people base their creations on fantasy litterature, role playing
	  games, dramas etc (there are whole MUDs out there built like that).
	  If you do, beware the copyright issues and if you use role playing,
	  know that numbers are impossible to translate from game to mud.


	1.2	Quality of descriptions
	It can be a good idea to look twice at the descriptions you have
	written. For example, adding views to a room by describing what can be
	found in adjacent rooms might be nice, but if that's all of the
	description, perhaps something should be added about the location
	itself? 


	1.3	Code quality.
	This is perhaps the easy part, as there is a tradition in computer
	science that deals with aspects of this. Here is a list of things that
	the NannyMUD admin thinks are aspects of code quality:

	+ No runtime errors. The players should not be presented with the ugly
	  'Your sensitive mind notices a wrongness in the fabric of space'
	  message. This is also all too often followed by a room that has no
	  long description and no exits.

	+ The code uses modern standard objects. Those are often optimised in
	  some way and most definitely actively maintained.

	+ The code honours the OOP style. Inheritance and overloading solves
	  most of your problem; don't re-invent the wheel all the time. 

	+ The code uses macros in a restrained way, for example as symbolic
	  constants. Replacing long chains of function calls with a macro can
	  make the code impossible to understand.

	+ The code is written to be read by humans not by the machine. This
	  means among other things that the code is systematically indented,
	  uses descriptive function and variable names, etc. Comment your code!

	+ Use description files, "headers", to describe objects that are non-
	  standard and/or complicated. This helps the admin when checking
	  things and you when returning to a project two years later.
	

	2.	Quality demand on an area for opening
	The demands on an area that is considered acceptable for opening are
	rather low; some would call it basic:

	+ All objects that are part of the area MUST load.

	+ All things in the area MUST be within the rules or approved.

	+ All intended exits MUST work.

	+ The area MUST use properties from the property system.

	+ You should have things and items in the area that can be examined
	  and possibly manipulated, but you don't need many of those.

	+ You should have some simple commands available for the player here
	  and there.


	3.	Quality demands on an open area.
	After it is opened, things will be monitored and perhaps adjusted as
	needed. Player input like bug, typo and idea reports should be taken
	seriously by the creator and acted upon. An area that does not improve
	will probably be closed sooner or later.


	4.	The NannyMUD tradition
	By tradition, NannyMUD has very little of quality control. Within the
	very wide borders of 'medieval fantasy with added magic' and the set of
	rules that unfortunately has been necessary to make during the years,
	wizards can create whatever they feel like, and in whatever way they
	see fit. More specifically:

	+ You don't have to use the standard objects. It is recommended that
	  you do, as it makes the life easier for players, you, other wizards
	  and the admin, but it isn't a demand.

	+ You don't have to follow a special coding style; you are free to use
	  your personal style in all your objects. If you don't like indented
	  code, you don't have to indent. You like macron? Fine, use them. It
	  is your privilege.

	Be warned however, that if you write code that only you can read and
	create objects that functions in ways no-one else can understand, you
	will be rather alone in debugging and trouble-shooting. The admin might
	not want to spend 2 hours peering at your code to find out what is
	wrong.

	
	5.	Why the NannyMUD tradition?
	NannyMUD is a Lysator project. Lysators policy is to allow people as
	much freedom as possible; this has then transferred to NannyMUD. It is 
	true that there was more freedom (less rules) in the early days when
	every wizard knew each other and the arches had time to help everyone.
	The growth of the game has made this impossible to uphold. Still, there
	are very low demands on an area before it can be opened.

	This has both advantages and disadvantages. Among the former are that
	wizards can grow in knowledge (learning by doing) and that new wizards
	will open areas faster; seeing obvious progress will hopefully help
	encouraging them to create further. Player input will help educate the
	new wizard, as well as show the weak points in the code.

	Among the disadvantages are that the code will be primitive, mistakes
	will be made that violates the rules and the game will be less well
	ordered. The admin will have to keep a closer eye on the game, thus
	their workload is increased by this system. There is a price to be paid
	for freedom, even the limited kind available in NannyMUD

SEE ALSO
	properties, RULES

Help topics available:

Syntax	acl	admin	ange-ftp	blocker
concept	damage_types	disk	feelings	ftp
quality	tasks	terrain	wizard	wizline
wizlevels	wizsoul	wiztool