CONCEPT
	std objects

LAST UPDATE
	Mateese, 07-Nov-1994, 22:00 MET

DESCRIPTION

	What are std-objects?

	  In short: objects already available in one of the
	top-directories, namely /std, /obj, /room, and /lib.
	These objects have been developed (and are still developed) by
	the Mud founders and wizards.

	How do I use them?

	  The exact details depend on the object itself, but you can
	use this rule of thumb:
	 - /std-objects may be cloned or inherited.
	 - /obj-objects should be cloned.
	 - /room-objects should be used as themselves.
	 - /lib-objects may be inherited or called to perform some
	   useful actions.
	Exceptions from this rule may always occur and should be
	documented.

	Why should I use them?

	  To spare your powers for the real creational tasks, instead
	of wasting them on re-inventing the wheel.
	The std-objects attempt to cover all those functionality which
	is needed again and again, like implementing the
	'lock'/'unlock'/'open'/'close' command combo for chests.
	As they are always 'under development', they are nearly
	bug-free, saving you from unnecessary debugging work, and your
	objects automatically profit from bugfixes and improvements.
	And a non-negligible side-effect is that they reduce the
	memory usage.

	Why must they be used?

	  To spare your powers for the real creational tasks, instead
	of wasting them on re-inventing the flat tire.
	This mudlib is admittedly complex, and the std-objects
	implement all the dirty groundwork for you, hiding it under a
	relatively simple wizard interface. If you would attempt to
	implement all those details on your own, you would certainly
	miss some, creating a spot of annoying inconsistency in the
	mudlib.

	But where is the fun of being a Wizard?

	  It's in the ability to create something new and fresh.
	Even though the std-objects have to be used, this doesn't mean
	that you are restricted to their functionality. In fact it's
	the other way round: use the std-object to get all the
	functions which already have been done, and built upon them
	new and fresh functions which have not been done yet.
	Or is it really that fun to program the 120th 'say-tool' which
	has less features than the builtin 'say'?

	Hmm, which std-objects should I use?

	  The most functional as possible, the least functional as
	needed.
	It really depends on what you are creating. You have to
	inherit /std/base at least, and better is to use /std/thing as
	minimum, but beyond that it's your decision.
	Select that std-object which implements the most of the
	functionality you need, and start building upon that.

	Where can I get further informations about them?

	  In the /doc-directories and the LPC-Examples.
	The doc files in /doc/... are grouped according to the objects
	they destribe: /std-objects have their files in /doc/std/,
	/obj-objects have their files in /doc/obj/, etc.
	The doc-files tend to be long and tech-talky, so there are
	examples for the most common uses in the
	/p/school/examples/-dirctory. Also feel free to
	experiment (that's what your workroom is for) and to ask.

	Is there a golden rule?

	  Small is beautiful.
	It is not the goal to produce lots of objects with lots of functions.
	Goal is to produce interesting objects, which are appreciative
	both in code and outer appearance.