Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!howland.erols.net!newsfeed.skycache.com!Cidera!news-reader.ntrnet.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Inform] Newbie Question
Message-ID: <G9DH42.BwJ@world.std.com>
Date: Mon, 26 Feb 2001 16:14:26 GMT
References: <20010224034714.16951.00002635@ng-mj1.aol.com> <G999oL.99w@world.std.com> <slrn99kp9o.ae.cerutti@fiad06.norwich.edu>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 73
Xref: news.duke.edu rec.arts.int-fiction:83911

Neil Cerutti:
>Sean T Barrett posted:
>>moving other objects.  Yes, it's a silly design and probably
>>shouldn't be that way for the tiny performance savings it gives.
>
>What would be easier? When the player moves, various bookkeeping
>tasks need to be done.

It is the design of the library to do these bookkeeping tasks as
a performance savings instead of querying them on the fly:

>  location=new_location;

allowing a global variable 'location' instead of

 getPlayerApparentLocation()

>  real_location=location;

allowing a global variable 'real_location' instead of

 getPlayerLocation()

>  MoveFloatingObjects();

there are other designs for floating objects; e.g. one could
move them before parsing the next command; they could exist
"automagically" in all the locations at once, etc.

>  AdjustLight(1);

instead of calling

 isPlayerRoomLit()

whenever you wanted to know. (Which could even cache the
result and only recompute if the player's location is
different from last time.)

>  ! Possibly award score points for arriving.

This is the only thing from your list that *needs* to be done
on player arrival, but generally when an author is herself
coding "move player to somelocation" they don't need this to
happen. Of course, they probably do want to print the room
description, and I believe playerTo is what sets the visited
flag to handle brief description processing, so the author
would have to call some other function to get this effect.

Yet even though this would be more work for the author, it
would at least behave consistently and predictably; the player
would really move and would really behave appropriately in the
new location, and the author would say "oh, that worked, but
it didn't print the room description, oops", instead of being
totally bewildered.

Of course, in an object-oriented system, "move player to X"
sends a message to the player, and the method for the player
move can do all the custom bookkeeping you want.  But the Inform
libraries aren't oh-oh; oh well.

In general, I dislike player-centric libraries, since they tend
to encourage hacks upon hacks (moveFloatingObjects, oh wait,
what about floor objects in rooms, oh wait, what about NPCs
in other rooms from the player, oh wait, what about)...
I don't believe pretending the player is in a special dark room to
prevent the player from referencing objects in the dark room
works well, and I will continue to criticize the Inform libraries
while using them to program perfectly tolerable, playable
games whose underlying implementations I loathe, at least
until something better comes along [tm].

SeanB
