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