physics
Paul Christopher Workman
How would you do something like this:
a person pours water over a rock face. most of the water
flows off into the ground below, but some of it forms
little puddles on indentations on the rock.
how could this be represented? Not only the general
characteristics of the rock but a fair amount of
detail would have to be included.
--paul
David Whitten
and some concept of a non-permeable surface.
Then you can represent the rock by a set of containers on the top, and
surfaces on the side. Then it is a matter of defining what happens when
you pour water on each of these objects. (It pools in the contents-space
of a container, but runs off a surface)
Clearly, the hard thing about this is having some kind of part-of hierarchy
so your rock can have various parts which have different characteristics,
and some kind of solid/liquid/gas interaction methodology.
Just my 2 zorkmids,
David (whi...@fwva.saic.com) US:(619)535-7764 [I don't speak as a company rep.]
Shane Kerr
>a person pours water over a rock face. most of the water
>flows off into the ground below, but some of it forms
>little puddles on indentations on the rock.
This is a problem in AI and simulation - how much detail do you need?
How much do you want? Personally, if I really wanted to do something
like this, I'd add a characteristic for objects that defined their
surface. So you'd have SuperSmooth for teflon, SmoothHighFriction for
glass, Fuzzy for yarn, and so on. Well, just an idea.
--
kerr(); /* no comment */
Neil K. Guy
Another major problem that comes to mind is the perennial difficulty
in modelling infinitely divisible stuff. All the text adventure
systems I've seen to date just define each manipulable item as a data
object. While this is fine for things like tables, frozen turkeys,
T-shirts and microprocessor-controlled electric egg crackers it
presents real problems for anything you might want to divide. It
becomes difficult enough if you want break an item - remove the legs
from the table, say - but what about a bowl of water or a bag of wheat?
Maybe I want to pour half the water into a plastic tub. You start
having to do all sorts of strange kludges to make these things work.
In my TADS-written adventure, for instance, I have a lake. This
should be setting off warning buzzers in anyone who's written a text
adventure. Lakes and such are a nuisance. How are you going to handle
swimming? Is it allowed? Does it get the player's clothing wet? And
with an essentially infinite supply of water the player might want to
fill every water-containing item with water for some reason. How do
you model that? I've basically had to create a potential water object
for each item that can act as a container for liquid. And then move
that object into the container if the player fills the item with
liquid. But even this sort of implementation creates as many problems
as it solves. You have to come to the point where you say - heck with
it! This is just a game and not a simulation of reality so you try to
make it reasonably convincing and playable and just leave it at that.
- Neil K. (n_k...@sfu.ca)
Greg Ewing
|> Another major problem that comes to mind is the perennial difficulty
|> in modelling infinitely divisible stuff.
I wrote a mini-adventure in TADS recently in which I dealt with exactly
this problem. My solution involved a class "substance" representing
something you can have varying amounts of, and a class "quantityHolder"
that knows how to contain varying amounts of different substances.
For example, you might have subtances "sand" and "water", and
quantityHolders "bottle" and "bucket".
Each quantityHolder has a list of [subtstance,amount] pairs representing
the amount of each substance it currently holds. Special methods of
quantityHolder are used to transfer specific amounts of substances
from one quantityHolder to another, etc., and various verbs such as
putIn are defined to do the appropriate things when applied to
substances and quantityHolders. There are also some new verbs
such as emptyInto which dumps the entire contents of one quantityHolder
into another.
I could post the source here if there was enough interest - or is there
another group that would be more appropriate?
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+
David Whitten
>In article <neilg.7...@sfu.ca>, ne...@fraser.sfu.ca (Neil K. Guy) writes:
>|> Another major problem that comes to mind is the perennial difficulty
>|> in modelling infinitely divisible stuff.
>
>I wrote a mini-adventure in TADS recently in which I dealt with exactly
>this problem. My solution involved a class "substance" representing
>something you can have varying amounts of, and a class "quantityHolder"
>that knows how to contain varying amounts of different substances.
>
>For example, you might have subtances "sand" and "water", and
>quantityHolders "bottle" and "bucket".
>
>Each quantityHolder has a list of [subtstance,amount] pairs representing
>the amount of each substance it currently holds. Special methods of
>quantityHolder are used to transfer specific amounts of substances
>from one quantityHolder to another, etc., and various verbs such as
>putIn are defined to do the appropriate things when applied to
>substances and quantityHolders. There are also some new verbs
>such as emptyInto which dumps the entire contents of one quantityHolder
>into another.
approach.
>
>I could post the source here if there was enough interest - or is there
>another group that would be more appropriate?
>
Phil Goetz
> Another major problem that comes to mind is the perennial difficulty
>in modelling infinitely divisible stuff. All the text adventure
>systems I've seen to date just define each manipulable item as a data
>object. While this is fine for things like tables, frozen turkeys,
>T-shirts and microprocessor-controlled electric egg crackers it
>presents real problems for anything you might want to divide. It
>becomes difficult enough if you want break an item - remove the legs
>from the table, say - but what about a bowl of water or a bag of wheat?
>Maybe I want to pour half the water into a plastic tub. You start
>having to do all sorts of strange kludges to make these things work.
The way I handled liquids in _Inmate_ was to have a bit flag an object as
a liquid. If it was a liquid, it had an additional set of rules to follow
in physical interactions, namely:
1. Can only be put into objects that have the "liquid container" bit set.
Putting them into anything else results in liquid on the floor, which I
think I evaporated (though it could have been just left there).
2. When it is put into a container, the contents of the container are
examined.
a. Things which are damaged by water (another bit) are destroyed.
(Can't remember whether I implemented this.)
b. If another object of the same liquid type is in the container,
that object's size is added to the size of the object you are
trying to put into the container, and the object is destroyed.
(This means 2 liquid objects combine into 1.)
3. An ordinary object goes into the container if (capacity - sum of sizes
of objects in the container) <= size(object). A liquid object goes in if
there is at least "1" size unit of capacity left. If there is not enough
capacity left for the entire liquid object, a new liquid object is created
in the destination, and given a size so that it fills the destination to
capacity. That size is subtracted from the original object.
(This means that liquid objects divide.)
4. A water object of size 255 (the largest size) was considered an
infinite source, e.g. a lake or water main. Attempting "put lake in can"
(which is what a sentence like "fill the can with water from the lake"
would be parsed into) would act as expected, but would not subtract the
size of the newly-created water object from the size of the lake.
I wanted to implement a "water-jug" puzzle, i.e. you have a
5-cup container and an 8-cup container, and need exactly 2 cups of water,
but didn't.
Phil go...@cs.buffalo.edu
Greg Ewing
Goetz) writes:
|> b. If another object of the same liquid type is in the container,
|> that object's size is added to the size of the object you are
|> trying to put into the container, and the object is destroyed.
|> (This means 2 liquid objects combine into 1.)
This is okay if your system can dynamically create objects, which
some systems don't let you do (e.g. ALAN, and (I think) TADS).
Not being able to instantiate objects can be quite a hassle.
Another situation that TADS does not handle well is the following:
There is a machine that dispenses Lotto tickets. You put some
money in, and it prints out a new ticket with some random numbers
on it and a unique serial number. There is a counter where you
can cash in a ticket and possibly win a prize.
TADS has problems with this on two levels: (1) You can't create
a new object to represent each lotto ticket. (2) There does
not seem to be a way of teaching the parser to understand
commands like "put lotto ticket 4365 on counter", because the
number will be treated as a reference to a Number object,
whereas you really want it to be an additional "adjective"
of a particular ticket.
Problem (1) is probably workable around in TADS, but (2) seems
to be insoluble because of the inflexibility of the parser.
Can anyone think of a solution?
Philip Stephens
>The way I handled liquids in _Inmate_ was to have a bit flag an object as
>a liquid. If it was a liquid, it had an additional set of rules to follow
>in physical interactions.
Here's another (admittedly simple) idea: why not have two properties
attached to an object:
1. The amount of liquid currently contained in that object. This would
be added to the size of the contents.
2. The noun describing what kind of liquid is in the object e.g. "water",
"tea", "coffee" and so on.
The "pour" verb will then simply transfer X units of liquid from one
container to the next, and the noun attached to the container will be used
to both describe what kind of liquid it is, as well as giving a name for
the player to use in the "pour" sentence.
e.g. "pour water from the jug."
Of course, there are two fundemental problems to be addressed in this
scheme:
1. How to pour liquid from one indirect object to another when most
parsers can't handle more than one indirect object. i.e. "pour water
from the jug in to the bucket." may not be understood by your favorite
parser.
2. What happens when you pour one kind of liquid into an object
containing another kind? Do we define nouns like "black coffee", "milk"
and "white coffee" to handle each of the desired combinations?
Still, this scheme would be quite adequate for filling up kettles from a
room containing a lake! I'll probably be implementing a scheme like this
in my upcoming 'newstandard.adl' for ADL (almost finished, for those who
care!).
--
| Philip Stephens, Systems Programmer. | %%%% % Labtam Australia Pty Ltd |
| Address: 43 Malcolm Road, Braeside, | % % % % "Applied Ingenuity" |
| Victoria, 3195, AUSTRALIA. | % % % % We make the fastest RISC |
| Internet: phi...@labtam.labtam.oz.au | %%%%% %%%%% X terminals in the world |