text adventure game problem

corvettecraz92 at gmail.com corvettecraz92 at gmail.com
Thu Apr 10 08:06:42 EDT 2008


On Apr 10, 3:14 am, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
> On Wed, 9 Apr 2008 05:25:19 -0700 (PDT), corvettecra... at gmail.com
> declaimed the following in comp.lang.python:
>
>
>
> > I can't even compile your code to see how it works, Dennis. I'm
> > confused about what that does.
>
>         My apologies -- it was spur of the moment pseudo-code to illustrate
> the concepts, but was never meant to be directly executable.
>
>         The concepts are that: all rooms are basically the same -- they have
> a list of objects that exist within the room (and, as I now realize, the
> "gold within the cabinet/cup" would still be an object within the room
> -- but would have an attribute "hidden=True" which would control if it
> is itemized when one "examines" the room), a list of exits, and a maybe
> a list of actions which can be performed in the room or on named objects
> (though I see the actions being common methods invoked by the command
> parser -- I illustrated a simple "verb object" command, but a good
> parser should probably accept more complex commands "throw <object1> at
> <object2>" for example). Uh, I'm saying "list", but "dictionary" would
> be the likely implementation.
>
>         When one "examines" a room, one essentially gets back a list of the
> objects that are in the room instance. When one "examines" one of those
> objects (by name), one gets back the detailed description of that
> object. If one implements a "hidden" attribute, that object will not be
> listed in the higher level "examine". That "gold" inside another object
> does get a bit tricky -- I now see it as a hidden object in the room,
> but the description of the object has to be somewhat dynamic -- that is,
> if the object (cabinet) sees that the "gold" is in the room, examining
> the object will report the gold. But a "take gold" command still acts on
> the room -- removing the gold from the room inventory, putting it into
> the player inventory, and changing the "hidden" property so it is now
> visible.
>
>         When one does a  "move <direction>", the player's "location"
> attribute is changed from the current room to the room connected to that
> direction.
>
>         For both objects and directions, if the player enters a term that is
> not in the relevant dictionary, a suitable message is returned to the
> user. Oh, room objects, besides that "hidden" attribute, may have a
> "portable" attribute which controls if one can "take" the object... Or
> an attribute for "throwable" which controls if one can throw an object
> at another (and the other would have a method/action for when something
> is thrown at it -- a default would be "No effect").
>
>         From what I saw of your small sample, you were treating each room as
> a discrete function. Moving from one room to another means calling the
> new room's function. But that means you are continuously nesting deeper
> in the Python stack, and someone that keeps moving back and forth
> between two rooms will eventually exceed the Python stack limit.
>
>         By making the "current location" an attribute of a "player
> instance", no recursion is involved -- you move between rooms by simply
> assigning the new room as the "current location".
>
> --
>         Wulfraed        Dennis Lee Bieber               KD6MOG
>         wlfr... at ix.netcom.com             wulfr... at bestiaria.com
>                 HTTP://wlfraed.home.netcom.com/
>         (Bestiaria Support Staff:               web-a... at bestiaria.com)
>                 HTTP://www.bestiaria.com/


okay, that explains it...
could you provide a working example of a two-room game using your
method please so I can understand it better? Thanks in advance!



More information about the Python-list mailing list