Message-ID: <3D1CEF36.9050804@csi.com>
Date: Fri, 28 Jun 2002 19:20:22 -0400
From: John Colagioia <JColagioia@csi.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: Re: Making a "found_in" object disappear
References: <3d169af2$0$79564$3c090ad1@news.plethora.net> <ab01df60.0206240804.18eee2e1@posting.google.com> <3d1bf8b3$0$79553$3c090ad1@news.plethora.net> <3D1C5179.9040301@csi.com> <3d1c6a7f$0$22477$3c090ad1@news.plethora.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: ool-182f30fa.dyn.optonline.net
X-Original-NNTP-Posting-Host: ool-182f30fa.dyn.optonline.net
X-Trace: excalibur.gbmtech.net 1025306036 ool-182f30fa.dyn.optonline.net (28 Jun 2002 19:13:56 -0400)
Organization: ProNet USA Inc.
Lines: 88
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:105560

Peter Seebach wrote:

>In article <3D1C5179.9040301@csi.com>,
>John Colagioia  <JColagioia@csi.com> wrote:
>
>>Might I suggest using one object for both, in such cases?  Recreate the
>>short_name, description, and other properties as methods which switch
>>based on the current mode.
>>
>>Not only will this free up some more objects (which might be an issue
>>for you, I don't know), but it'll be slightly faster than a bunch of
>>objectloops, *and* it'll make the delays "on-demand" and much shorter
>>each time they occur.
>>
>In those cases, perhaps... in some cases, though, the object is just
>plain gone in one mode.
>

You must be a bit sneakier, then.  I'll try to wrap up the whole thing
in a second.

>Also, how do I change the name list?  If an object
>changes from being a rushing river to a stagnant pool, I don't want "river"
>to refer to the pool.
>

Which is perfectly fair.  Here's how I'd try to attack both these points:

Class MagicThing
  with  normal_name,
        magic_name,
        parse_name
                [ wd prop num ;
                 wd = NextWord ();
                 if (actor.magic)
                        prop = magic_name;
                 else   prop = normal_name;
                 while (WordInProperty (wd, self, name))
                        {
                          ++ num ;
                          wd = NextWord ();
                        }
                 return (num);
                ],
        react_before
                [ ;
                 if (action == ##Look && self has general && actor.magic)
                        give self scenery;
                 else   give self ~scenery;
                ],
        description
                [ ;
                  if (actor.magic)
                         PrintOrRun (self, normal_description);
                  else   PrintOrRun (self, magic_description);
                ],
        normal_description,
        magic_description;

It's just a rough sketch (it was a *little* harder than I thought, but I
eventually stumbled on the react_before solution for hiding things), but
I just tested it, and everything seemed to work.  In particular, when
the actor's magic property is set (you can change this, of course, to
whatever you like), it'll choose name words from magic_name and print
the description from magic_description; otherwise the normal_* versions
will be used (you could probably use just "name" and "description"
properties, here, but I wanted to emphasize the differences).

Similarly, if the object in question has the general Attribute (again,
change this to whatever you want), it can't be seen (it's "scenery").
 If the player can't see a description (because it's scenery) and can't
refer to it (because magic_name has no words in it), then the object
doesn't exist from the player's perspective.

>>You'd do a former professor of mine proud.  His philosophy was "first
>>make it work right, then make it work well."  I do tend to agree, though
>>it's sometimes more fun to play with optimization problems up-front....
>>
>In this particular case I'm thinking that the performance issue merits a
>rethink of the design.
>

Yeah, I suppose the amount of rewriting that would be necessary makes
predesign a better idea.

I hope my partial solution puts you closer to the path you're looking
for, at least.

