From the NannyMUD documentation

LAST CHANGE

2000-12-16

TOPIC

NAME
        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 certaintydiffer.
	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 design 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
	  macros? 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 in build/properties


SEE ALSO
        RULES in RULES/rules