CONCEPT
	virtual objects

UPDATE
	Mateese, 17-May-95 - 01:00 MET

DESCRIPTION
	One problem of LPMud is that each room or object needs an own
	file for its description - even if it is just a simple child
	of a standard object. The solutions so far were the usage of
	replace_program() for rooms and clone_object() for things, but
	they are intended to reduce the memory usage in core, and
	still need special code to be used.
	Virtual objects offer a way to transparently deal with
	rooms/objects which in fact aren't there.

	When the gamedriver is asked to load object "/d/micro/bar", it
	first looks for the file "/d/micro/bar.c". If it exists, it is
	read and compiled.
	If it doesn't exist, it calls the /secure/master and expects
	it to return either an object or 0. If 0 is returned, the
	driver decides this object as being unloadable and issues the
	well-known 'Can't load file' error.
	However, if the master returns an object, it is named
	"/d/micro/bar" and the load succeeds. That the object may be
	in fact a clone of "/std/thing" is no longer of interest then.

	The strategy the master implements is that it calls the lfun

	  object compile_object (string filename)

	in the object causing the load, <filename> is of course the
	name of the object to be loaded.

	The loading object may redirect this call to a "master" object
	by setting its property P_VMASTER ("VMaster") to the name or
	the object of that master object. If it is given, the lfun is
	called in the master object instead of the loading object.


USAGE
	Imagine that you are creating a grass plain of 10*10 rooms.
	Without virtual objects, you had to code each of the 100 rooms
	on its own. The alternative were mazemasters, which are fed
	some sort of description of the 100 rooms, and would create
	clones of special rooms to implement the areal.
	In the former case you have to write a lot of redundant text,
	in the latter case it is difficult to insert rooms which are
	more than just "grassy plain".

	Utilizing a virtual object master, you can condense the
	descriptions of the 100 rooms into one file which is fed to
	the virtual master. But each description is written as if the
	100 rooms were coded on file-basis, thus making it easy to add
	extraordinary rooms.

	Say that the plain would be in /d/micro/plain/*, and the rooms
	were named /d/micro/plain/<x>,<y>.c. When writing the
	description file for the area, you link the exits by their
	names, e.g. /d/micro/plain/1,1.c has an exit south to
	/d/micro/plain/1,11.c . It doesn't matter that
	/d/micro/plain/1,11.c doesn't exist as own file -- the virtual
	master will be called and provide a suitable object for it.
	On the other hand you can make make room 1,11 something
	special simply by providing a dedicated /d/micro/plain/1,11.c
	file. The only predicament you have to take is that
	/d/micro/plain/1,11.c set P_VMASTER pointing to the plains
	virtual master - else the surrounding rooms can't be
	connected.

WARNING
	Virtual rooms make it very tempting to 'write' vast landscapes
	with lots of nature, but no action. Or even worse: mazes.
	To quote Graham Nelson (author of "Inform", an Infocom-Compiler):

	"4.  Density

	Once upon a time, the sole measure of quality in
	advertisements for adventure games was the number of rooms.
	Even quite small programs would have 200 rooms, which
	meant only minimal room descriptions and simple puzzles which
	were scattered thinly over the map.

	Nowadays a healthier principle has been adopted: that (barring
	a few junctions and corridors) there should be something out
	of the ordinary about every room.

	One reason for the quality of the "Infocom" games is that the
	version 3 system has an absolute maximum of 255 objects, which
	needs to cover rooms, objects and many other things (eg,
	compass directions, or the spells in "Enchanter" et al).  Many
	"objects" are not portable anyway: walls, tapestries, thrones,
	control panels, coal-grinding machines and so on. 

	[...]

	6.  Mazes

	Almost every game contains a maze.  Nothing nowadays will ever
	equal the immortal

	  You are in a maze of twisty little passages, all alike.

	But now we are all jaded.  A maze should offer some twist
	which hasn't been done before (the ones in "Enchanter" and
	"Sorcerer" being fine examples).

	The point is not to make it hard and boring.  The standard
	maze solution is to litter the rooms with objects in order to
	make the rooms distinguishable. It's easy enough to obstruct
	this, the thief in "Zork I" being about the wittiest way of
	doing so.  But that only makes a maze tediously difficult.

	Instead there should be an elegant quick solution: for
	instance a guide who needs to be bribed, or fluorescent arrows
	painted on the floor which can only be seen in darkness (plus
	a hint about darkness, of course). 

	Above all, don't design a maze which appears to be a standard
	impossibly hard one: even if it isn't, a player may lose heart
	and give up rather than go to the trouble of mapping it.
	"

SEE ALSO
	perception(C), foundp(SEFUN), sort_findings(SEFUN)
	/doc/papers/howtowriteIF, /doc/papers/craftOfAdventure
