Inform: How to make TINY container?
Julian Arnold
> I have a problem. I want to make a little medicine canister that will
> hold tiny things, i.e. a dime, a bunch of pills, a peanut.. but NOT
> things like a portable radio, a shirt, etc. How can I manage this
> effect?
How about this:
#ATTRIBUTE tiny;
#OBJECT canister "medicine canister"
with name "medicine" "canister",
description "It's very small. You probably can't get much in.",
before [;
Receive:
if (noun hasnt tiny)
print_ret "You just can't cram ", (the) noun, " into \
the canister.";
rfalse;
],
capacity 3,
has container openable open;
Then objects such as a dime, a bunch of pills, a peanut, etc. have tiny,
while a radio, a shirt, etc. do not.
Hope this helps,
Jools
--
Julian Arnold jo...@arnod.demon.co.uk
Sam Hulick
I have a problem. I want to make a little medicine canister that will
hold tiny things, i.e. a dime, a bunch of pills, a peanut.. but NOT
things like a portable radio, a shirt, etc. How can I manage this
effect?
--
--- Sam Hulick ------------- shu...@indiana.edu ---------------------
Systems Consultant | Homepage:
Indiana College Placement | http://copper.ucs.indiana.edu/~shulick/
and Assessment Center | PGP public key available on request
Sam Hulick
>"Sam Hulick" (shu...@blueberry.ucs.indiana.edu) wrote:
>
>> I have a problem. I want to make a little medicine canister that will
>> hold tiny things, i.e. a dime, a bunch of pills, a peanut.. but NOT
>> things like a portable radio, a shirt, etc. How can I manage this
>> effect?
>
>
> #ATTRIBUTE tiny;
I was thinking about that, but I have so many attributes and properties
already! OH well... *grin*
P.S.: Is there any limit to the amount of attributes and properties in a
game?
Sam Hulick
>"Sam Hulick" (shu...@blueberry.ucs.indiana.edu) wrote:
>
>> I have a problem. I want to make a little medicine canister that will
>> hold tiny things, i.e. a dime, a bunch of pills, a peanut.. but NOT
>> things like a portable radio, a shirt, etc. How can I manage this
>> effect?
>
>How about this:
>
> #ATTRIBUTE tiny;
>
> with name "medicine" "canister",
> description "It's very small. You probably can't get much in.",
> before [;
> Receive:
> if (noun hasnt tiny)
Correction. inp1, not noun.
Julian Arnold
> jo...@arnod.demon.co.uk writes:
> >"Sam Hulick" (shu...@blueberry.ucs.indiana.edu) wrote:
> >
> >How about this:
> >
> > #ATTRIBUTE tiny;
>
> I was thinking about that, but I have so many attributes and properties
> already! OH well... *grin*
Have you tried aliasing attributes/properties? Maybe `#ATTRIBUTE tiny ALIAS
visited'. There shouldn't be a conflict of interests as visited is only used
for rooms and tiny is only used for manipulable objects. This being said I
think Jim Newland's size/volume properties solution was better than my tiny
attribute, but you can alias properties too.
It's best to look at parser.h first though, as some attributes/properties are
already aliased which could cause headaches.
Regards,
Jim Newland
>> I have a problem. I want to make a little medicine canister that
>>will hold tiny things, i.e. a dime, a bunch of pills, a peanut.. but
>>NOT things like a portable radio, a shirt, etc. How can I manage
>>this effect?
>
>
> #ATTRIBUTE tiny;
}I was thinking about that, but I have so many attributes and
}properties
}already! OH well... *grin*
The "attribute tiny" approach works all right when there are only a few
objects and one or two possible containers. With larger numbers of
things, it becomes unworkable. A better approach in that case is to
assign two new properties, "size" and "volume" (or something like that,
since "capacity" is already taken, if I remember correctly). Assign
each object a size and each container a volume. Then write a routine to
check the container to see whether there is enough room left in it to
contain whatever object the player is trying to put there, and call it
whenever he/she tries to.
This doesn't answer your objection about not having enough properties
and such left to work with, but, in my experience, if you're running
out of these things, you're probably not coding things as efficiently
as you could be (are you making good use of the "general" attribute,
for instance?). Either that, or you have one hell of a big game going
there.
}P.S.: Is there any limit to the amount of attributes and properties in
}a game?
Yep. Compile with the -s switch to see what they are. Some limits can
be raised, too. Run "inform $list" to see which ones they are and how
to do it (unfortunately, attributes and, I believe, properties, are not
among them).
Jim Newland
76461...@compuserve.com
Gareth Rees
> [limits on attributes and properties]
In my opinion, the limits on attributes and properties imposed by the
Z-machine are the main area in which Inform loses out to TADS (the other
main areas are dynamic memory allocation and multiple undo).
Any kind of serious commitment to the object-oriented style of
programming demands the storing of data with objects, but with only 48
attributes and 62 properties (and the limit of 64 bytes for static data
stored in a property), this is difficult to do successfully.
Here's some genuine (and utterly unlovely) code from "Christminster"
(with a couple of spoilers removed) showing one way to organise the
mapping from property names to properties:
Property mypropa 0;
Property mypropb 0;
Property mypropc 0;
Property mypropd 0;
Property myprope 0;
Property mypropf 0;
Property next_cup alias mypropa; ! Next cup in order (for trick)
Property cellarer alias mypropa; ! Names on wine storage bins
Property occupant alias mypropa; ! Name of person on is_door
Property just_visited alias mypropa;! Last place visited by is_followable
Property other_obj alias mypropa; ! Other object in pair (eg griffins)
Property near_to alias mypropa; ! Phone wire box is near to this
Property room alias mypropb; ! Name of room on is_door
Property follow_dir alias mypropb; ! Which way is_followable went
Property trickobject alias mypropc; ! Object involved in busker's trick
Property honorific alias mypropc; ! Honorific on is_door
Property trickcup alias mypropd; ! Which cup was first used in trick
Property trickcount alias myprope; ! No of different cups looked under
Property doesnt_obey alias mypropf; ! TalkableClass default message
--
Gareth Rees
Andrew C. Plotkin
> jo...@arnod.demon.co.uk writes:
> >"Sam Hulick" (shu...@blueberry.ucs.indiana.edu) wrote:
> >
> >
> > #ATTRIBUTE tiny;
>
> I was thinking about that, but I have so many attributes and properties
> already! OH well... *grin*
>
> game?
Yes:
A V3 Inform program may define up to 30 properties, and V4 or later up
to 62.
A V3 Inform program may define up to 32 attributes, and V4 or later up
to 48.
The libraries define nearly 30 of each, but if you're using V5 you're
unlikely to run out. If you get close, you can start using "alias" to
consolidate attributes which you know don't occur in the same object.
Ditto for properties.
This is, of course, all documented.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Andrew C. Plotkin
> Jim Newland <76461...@CompuServe.COM> wrote:
> > [limits on attributes and properties]
>
> In my opinion, the limits on attributes and properties imposed by the
> Z-machine are the main area in which Inform loses out to TADS (the other
> main areas are dynamic memory allocation and multiple undo).
>
> Any kind of serious commitment to the object-oriented style of
> programming demands the storing of data with objects, but with only 48
> attributes and 62 properties (and the limit of 64 bytes for static data
> stored in a property), this is difficult to do successfully.
I find that my commitment to debugging vastly outweighs my commitment
to OO-style code. So I use global variables instead of properties if
the data applies to a single object. It's easier than worrying about
collision between aliased properties.
For that matter, OO-style *programming* does not mean you must use the
OO-style *features* in the particular language in question. The fox in
Weather has several global variables associated with it, and they are
logically part of the fox object.
Of course, globals are limited in Inform too. Sigh.