Hard rocks, soft teddybears, fragile glass
Nicholas Shore
I was wondering just now about the original thread of Throwing Shoes at
Lights, and I came up with the thought of how hard it would be to integrate
ingame-item attributes, such as soft, hard, fragile, etc.
You'd have to agree on a few useful ones, but I think it should be possible.
That would make more complex item interactions possible, so that to open a
door for example you could either waste time looking for a key or simply
bash the door in with a rock. It certainly would certainly enhance the OO
aspects of environment interaction.
You have to watch out with things like dropping items, I guess, it would be
frustrating to have to >put wineglass down carefully<, but the logical
conclusion of >throw wineglass< should be a broken wineglass.
I'd be interested to hear what more experienced coders think about this
subject.
Nicholas
okbl...@my-deja.com
"Nicholas Shore" <nds.bl...@gmx.de> wrote:
>
> I was wondering just now about the original thread of Throwing Shoes
at
> Lights, and I came up with the thought of how hard it would be to
integrate
> ingame-item attributes, such as soft, hard, fragile, etc.
Not hard at all.
> You'd have to agree on a few useful ones, but I think it should be
possible.
> That would make more complex item interactions possible, so that to
open a
> door for example you could either waste time looking for a key or
simply
> bash the door in with a rock. It certainly would certainly enhance the
OO
> aspects of environment interaction.
All you've done, though, is shift the complexity from managing objects
to managing behaviors, if you want to control the story flow. The
author must take care to make sure that hard, heavy objects, for
example, are not available to break down the door (if not desired)
and/or that the character must respond to the attempt.
The author must begin to think less in terms of "using the knife to cut
the rope" and "using any sharp object". Ultimately, this might be a
good thing, of course. But it's also often not appropriate.
--
[ok]
Sent via Deja.com http://www.deja.com/
Before you buy.
Nicholas Shore
<okbl...@my-deja.com> schrieb im Newsbeitrag
news:87njfi$c06$1...@nnrp1.deja.com...
> In article <87n1eu$fmb$1...@infosun2.rus.uni-stuttgart.de>,
>
> The author must begin to think less in terms of "using the knife to cut
> the rope" and "using any sharp object". Ultimately, this might be a
> good thing, of course. But it's also often not appropriate.
>
> --
> [ok]
increase the player freedom and work in the direction of multiple-solution
puzzles? I mean, hell, what does MacGyver do all day?
I think this could lead to a renaissance of puzzle oriented IF.
Nicholas Shore
Emily Short
----------
In article <87n1eu$fmb$1...@infosun2.rus.uni-stuttgart.de>, "Nicholas Shore"
<nds.bl...@gmx.de> wrote:
>Hi all,
>
>I was wondering just now about the original thread of Throwing Shoes at
>Lights, and I came up with the thought of how hard it would be to integrate
>ingame-item attributes, such as soft, hard, fragile, etc.
>You'd have to agree on a few useful ones, but I think it should be possible.
>That would make more complex item interactions possible, so that to open a
>door for example you could either waste time looking for a key or simply
>bash the door in with a rock.
Okay.
I had way too much to do tonight, so instead of doing it, I wrote a little
demonstration of this general principle. It has been tested, but not with
the same degree of rigor with which I would test a Real Game. So consider
it beta. But if you're interested, it's in gmd.de/if-archive/incoming/
under the name "Peacock.z5".
ES
okbl...@my-deja.com
"Nicholas Shore" <nds.bl...@gmx.de> wrote:
>
> O.k. it would need new ways of thinking as a author, but wouldn't it
also
> increase the player freedom and work in the direction of
multiple-solution
> puzzles? I mean, hell, what does MacGyver do all day?
> I think this could lead to a renaissance of puzzle oriented IF.
Hrm, I doubt that, for this reason: The detail required in the game
world, the precision of expression of action, and ultimately the
knowledge required of the player are much greater than exists today.
It could be done on a very basic level, i.e., any sharp object could be
used to cut a rope. Any climbable or stackable-and-climbable object
could be used to scale a height.
If the puzzle is the *point*, however, then the author's going to take
pains to limit the solutions. In any event, the truly ingenious
solutions are going to have been anticipated.
If the player can break down various objects into chemicals used in
making explosives, for example, the author has to add an isExplosive
type property, and having done that, must anticipate all the places
explosives might be used, and so on.
I wouldn't mind seeing more expendable objects in IF, of course, so that
if what the author thought was an obvious solution wasn't obvious to me,
I could use what *I* thought was obvious.
Mary J Mcmenomy
: opens up a lot of possibilities for making a game unwinnable. Plus you need
: the possibility of putting a fire out again after you've started it. (You
: could put in a safe mode, so that the computer tells you when destroying
: something might be a bit stupid.)
A trivial point, but you can (sometimes) put things out in the demo with
the formulation
>BLOW ON <thing>
Maybe an example of guess-the-verb-ism, if you tried some other way
without success.
And no, I do not think this would be a good place to implement "use."
--
Mary McMenomy
Department of Classical Studies
University of Pennsylvania
Nicholas Shore
"Emily Short" <ems...@mindspring.com> schrieb im Newsbeitrag
news:87orh5$pk6$1...@nntp2.atl.mindspring.net...
>
>
> I had way too much to do tonight, so instead of doing it, I wrote a little
> demonstration of this general principle. It has been tested, but not with
> the same degree of rigor with which I would test a Real Game. So consider
> it beta. But if you're interested, it's in gmd.de/if-archive/incoming/
> under the name "Peacock.z5".
>
> ES
I checked out your demo, and now I see the difficultees pointed out by OKB.
You do have to take very great pains to anticipate the players actions. I
does seem fun to be able to burn everything burnable in sight, except it
opens up a lot of possibilities for making a game unwinnable. Plus you need
the possibility of putting a fire out again after you've started it. (You
could put in a safe mode, so that the computer tells you when destroying
something might be a bit stupid.)
I also found that with the added item attributes you need more verbs, like
sawing, prying open, levering open, putting out (fire), picking locks, etc.
Plus you need every subobject described on an object, like the lock on a
chest, to be an manipulateble object of its own, so you need ways or
referencing them in a unique manner, like 'break the lock on the metal box',
or 'break the handle of the watering can'. (I don't know why all my examples
now are about destroying things, but unfortunately that's always the first
thing that comes to mind.)
I would concur with OKB that this considerably increases the effort of
writing If, and therefore will probably remain scarce.
On the other hand the author's necessity to preconsider many player actions
should lead to more complex games. And anybody that has ever designed
adventures for RPG's knows that anticipating player moves is very necessary
in a completely free environment. Unfortunately the computer lacks the game
master's ability of improvisation.
You'd have to go to very great depths to create a complete physical system
before the computer could respond sensibly to unforeseen actions.
Nicholas
Emily Short
----------
In article <87pq15$gn2$1...@infosun2.rus.uni-stuttgart.de>, "Nicholas Shore"
<nds.bl...@gmx.de> wrote:
>Emily,
>
>I checked out your demo, and now I see the difficultees pointed out by OKB.
>You do have to take very great pains to anticipate the players actions. I
>does seem fun to be able to burn everything burnable in sight, except it
>opens up a lot of possibilities for making a game unwinnable.
Of course. I see a couple of possibilities here:
1. Don't bother to prevent the game from becoming unwinnable. Create a
new game-play paradigm in which the player understands that burning
something apparently harmless might be a bad idea. Also, make sure that
you always provide "undo."
2. Have the game take note when you're about to remove from the game, eg,
the last of the seven priceless objets d'art you could use to bribe the
troll. This would be deeply annoying to program and would take away some of
the fun of the openendedness. But then, I don't feel cheated if the game
becomes unwinnable: I'm one of those insane players who save every ten moves
and finish a game like Curses with over a megabyte of save files, all with
inscrutable names like Cups139.
***
Plus you need
>the possibility of putting a fire out again after you've started it. (You
>could put in a safe mode, so that the computer tells you when destroying
>something might be a bit stupid.)
>I also found that with the added item attributes you need more verbs, like
>sawing, prying open, levering open, putting out (fire), picking locks, etc.
***
Not a prohibitive list of suggestions, per se. "Saw" would just be an
extension of "cut," which already exists. ("Blow out" is implemented,
though apparently not fully enough for you to have figured it out. And I
may have neglected to mention it if you type "help." Sorry.) Prying and
levering, and locks you can pick, are also *relatively* trivial.
The point I wanted to demonstrate is that it is indeed possible to
set up a flexible system allowing a range of puzzle solutions
from the brutish to the painstaking -- I took your idea of "search for
the key or bash in the door?" and ran with it. There's nothing very clever
in the demo. But there are a lot of different combinations that will get
you to the right ending, and while I've tested them all, I think, I didn't
anticipate them all per se. What I did was sketch out a selection of
objects that I thought would be fun to play with; assigned them some
predefined qualities; and let 'er rip. When I found that I'd created an
insoluble problem, I implemented at least one solution.
This is (I gather) the reverse of the way one would normally design a
puzzle, but I think such an approach has positive implications for the
story/puzzle interface. Some time ago some of us were discussing puzzles
in Varicella, and how those that developed naturally from the game
environment worked better than those that were separately conceived. So
with a complex, open-ended world model I envision the following IF-writing
methodology:
1. Come up with the setting and the major plot junctures.
2. Figure out what the player has to do to get from one juncture to the
next.
3. Fill the setting with props appropriate to the location/situation.
4. Consider: can the player use these props to solve any problems that
stand between her and the next progress point? If not, figure out
what's needed and include it somewhere.
One could use this methodology now, of course, but the more complex the
world-model, the more likely it will be that the game will produce its own
fitting-but-unplanned solutions. This may strike people as perverse: I'm
aware that a lot of authors spend their time trying to prevent players
from solving puzzles by any but the maximally clever method. But my goal
is to allow the player to do fairly ingenious things without breaking the
feel and the flow of the story.
A neat twist would be if the game somehow kept track of *how* the player had
solved various problems and used that information subtly to shape the player
further. So if you had a player who was always smashing things in order to
get to the end, the NPCs (or snarky parser comments) would treat the PC as a
clod; whereas one employing Odyssean cunning would be regarded with respect.
Or perhaps seen as a bit of a priss.
(This proceeds into a dark territory where the game assesses the player as
much as the player the game. Shades of _Diamond Age_, and _Ender's Game_.
Fortunately we're not nearly there yet.)
***
>I would concur with OKB that this considerably increases the effort of
>writing If, and therefore will probably remain scarce.
Not necessarily. This is what the original shoe-and-light comment was
about, IIRC (wasn't that Graham, weeks and weeks ago?). If one develops a
sufficiently thorough world-model, there's no reason why its libraries
shouldn't be easily usable from that point on. The fact that I was able
to bang out this (admittedly in some respects crude) example in the course
of a few hours, and with minimal sleep, means that other people could
probably use similar libraries to better ends.
The Real Trick, as I see it, is that you would want to raise the complexity
bar all at once: not by developing here a library for burning things and
there a library for liquids, but one library that took care of both and
understood what would happen if you poured water on the fire. So the
modules need to slot into each other.
It's this kind of thinking that's prevented my releasing an actual game any
time the last three years.
ES
Nicholas Shore
>
> ----------
> Of course. I see a couple of possibilities here:
>
> 1. Don't bother to prevent the game from becoming unwinnable. Create a
> new game-play paradigm in which the player understands that burning
> something apparently harmless might be a bad idea. Also, make sure that
> you always provide "undo."
>
burning something intentionally. You might tip up a candle and burn the
house down, or light a fire and burn down the Magic Forest, or something
like that. E.g. I set fire to your sea-worn chest, and burnt the sheet of
paper that was lying on the panel to take the rubbing as well. When all I
had actually wanted was some ash to take the rubbing.
>
> Not a prohibitive list of suggestions, per se. "Saw" would just be an
> extension of "cut," which already exists. ("Blow out" is implemented,
> though apparently not fully enough for you to have figured it out. And I
> may have neglected to mention it if you type "help." Sorry.) Prying and
> levering, and locks you can pick, are also *relatively* trivial.
Obviously I didn't say it was excessively difficult, you just need to take a
few more thoughts about additional verbs.
>
> The point I wanted to demonstrate is that it is indeed possible to
> set up a flexible system allowing a range of puzzle solutions
> from the brutish to the painstaking -- I took your idea of "search for
> the key or bash in the door?" and ran with it. There's nothing very
clever
> in the demo. But there are a lot of different combinations that will get
> you to the right ending, and while I've tested them all, I think, I didn't
> anticipate them all per se. What I did was sketch out a selection of
> objects that I thought would be fun to play with; assigned them some
> predefined qualities; and let 'er rip. When I found that I'd created an
> insoluble problem, I implemented at least one solution.
>
The actually difficult step is creating a working and plausible cause-effect
system. I just remembered that when I was about twelve or (can't have been
much older) I started to write a text-adventure in BASIC, without any OO or
libraries, just a selection of options for ever location, where I had to
anticipate what the player would want to do. In that game you came upon a
series of traps you had to disable. For example there was a cave with
concealed dart launchers in the walls. You could either fill up the dart
holes with wood chips, or use your knife to pry the arrows out of the wall,
or you could disable the stepping-stone trigger by jamming it with chips of
wood.
Now your system would have to be intelligent enough to see the trap as
whole, and not as a series of individual objects. The cause effect system in
the game would have to be detailed enough to enable the player to take not
just those particular foreseen actions, but any action that could disable
the trap. You'd get a long way with a sophisticated collision check, but in
a text adventure that would already go very far toward designing your
locations in 3D, and then 'reducing' them to words again.
> This is (I gather) the reverse of the way one would normally design a
> puzzle, but I think such an approach has positive implications for the
> story/puzzle interface. Some time ago some of us were discussing puzzles
> in Varicella, and how those that developed naturally from the game
> environment worked better than those that were separately conceived. So
> with a complex, open-ended world model I envision the following IF-writing
> methodology:
>
> 1. Come up with the setting and the major plot junctures.
>
> 2. Figure out what the player has to do to get from one juncture to the
> next.
>
> 3. Fill the setting with props appropriate to the location/situation.
>
> 4. Consider: can the player use these props to solve any problems that
> stand between her and the next progress point? If not, figure out
> what's needed and include it somewhere.
>
Obviously you have put a lot of thought into this already, and as far as I
see with the necessary libraries the system is sound.
> One could use this methodology now, of course, but the more complex the
> world-model, the more likely it will be that the game will produce its own
> fitting-but-unplanned solutions. This may strike people as perverse: I'm
> aware that a lot of authors spend their time trying to prevent players
> from solving puzzles by any but the maximally clever method. But my goal
> is to allow the player to do fairly ingenious things without breaking the
> feel and the flow of the story.
>
That would surely be a step in the right direction. The difficult step then
is to keep the player on the track of the story.
> A neat twist would be if the game somehow kept track of *how* the player
had
> solved various problems and used that information subtly to shape the
player
> further. So if you had a player who was always smashing things in order
to
> get to the end, the NPCs (or snarky parser comments) would treat the PC as
a
> clod; whereas one employing Odyssean cunning would be regarded with
respect.
> Or perhaps seen as a bit of a priss.
>
I don't see a possibility of creating a flowing transition between 'player
states', but a statistical system should do the job of evaluating player
actions, possibly by grading every significant action into several
categories, from brutish to clever. And interactions with the NPC's could
work accordingly, expecially if you graded the NPC's into the same
categories. You could even set up a system of sympathy or admiration, so
that a stupid NPC would admire (or fear, for that matter) a smart player,
and a smart NPC would look down on your classical
elephant-in-the-glass-house type of player.
> (This proceeds into a dark territory where the game assesses the player as
> much as the player the game. Shades of _Diamond Age_, and _Ender's Game_.
> Fortunately we're not nearly there yet.)
>
> If one develops a
> sufficiently thorough world-model, there's no reason why its libraries
> shouldn't be easily usable from that point on. The fact that I was able
> to bang out this (admittedly in some respects crude) example in the course
> of a few hours, and with minimal sleep, means that other people could
> probably use similar libraries to better ends.
>
Well, obviously it would be a team effort, and considering the fact that IF
is so far a minimal-profit, more or less my-gain-is-your-gain community a
freeware library could be improved and complemented by every author. This
might lead to an accomplished work some time.
> The Real Trick, as I see it, is that you would want to raise the
complexity
> bar all at once: not by developing here a library for burning things and
> there a library for liquids, but one library that took care of both and
> understood what would happen if you poured water on the fire. So the
> modules need to slot into each other.
As I said it's not only a matter of making modules slot into each other, you
need to go to a level below that and develop a complete physical system,
including collision checks, deformation checks (possibly with finite-element
simulations), energy transformations, and ultimately even chemical
reactions, and that would definitely be the end of palm-top IF, as you'd
need a lot of a modern computers cpu-power to evaluate the matrices that
would result in. Actally it would go beyond IF completely, what we are
talking about here is a step toward virtual reality computing.
You could keep it simpler of course, but the result of a simpler system
might be more difficult for a player to adapt to than the fixed-puzzle-type
worlds we can create at present.
> It's this kind of thinking that's prevented my releasing an actual game
any
> time the last three years.
It obviously puts an effective stop on slapping out games at short notice.
>
> ES
I hope this inspires you further.
Nicholas
Emily Short
----------
In article <87rk0g$pta$1...@infosun2.rus.uni-stuttgart.de>, "Nicholas Shore"
<nds.bl...@gmx.de> wrote:
>"Emily Short" <ems...@mindspring.com> schrieb im Newsbeitrag
>news:87q8hm$rfl$1...@nntp1.atl.mindspring.net...
>> 1. Don't bother to prevent the game from becoming unwinnable. Create a
>> new game-play paradigm in which the player understands that burning
>> something apparently harmless might be a bad idea. Also, make sure that
>> you always provide "undo."
>>
>When you're talking about realistic fire models, it not always a problem of
>burning something intentionally. You might tip up a candle and burn the
>house down, or light a fire and burn down the Magic Forest, or something
>like that. E.g. I set fire to your sea-worn chest, and burnt the sheet of
>paper that was lying on the panel to take the rubbing as well. When all I
>had actually wanted was some ash to take the rubbing.
Well, yes. But this seems fair. Bear in mind that the kind of game I'm
envisioning would be inherently harder to close off than the traditional
sort.
I should implement "heap of ashes" as a result of burning, the way you get
"shards of glass" when you break glass. But ash is one of those pesky
objects that need a container to be carried around, which is why I've been
putting it off until I have divisible liquids.
>The actually difficult step is creating a working and plausible cause-effect
>system. I just remembered that when I was about twelve or (can't have been
>much older) I started to write a text-adventure in BASIC, without any OO or
>libraries, just a selection of options for ever location, where I had to
>anticipate what the player would want to do. In that game you came upon a
>series of traps you had to disable. For example there was a cave with
>concealed dart launchers in the walls. You could either fill up the dart
>holes with wood chips, or use your knife to pry the arrows out of the wall,
>or you could disable the stepping-stone trigger by jamming it with chips of
>wood.
>Now your system would have to be intelligent enough to see the trap as
>whole, and not as a series of individual objects.
Why? I'd write it this way: have a trigger object and an arrows object.
The trigger object responds to stimulus, checks its own state, and if it
finds itself ready to fire, sends a message to the arrows object. The
arrows object then checks *its* state (are the arrows still in the wall? is
the player in scope?) and fires if appropriate.
The point isn't to model as elaborately as possible; it's to model as
elaborately as *necessary.* I started this project as a way to eliminate
messages like "Cutting that up would achieve little." I don't envision
expanding the verb set vastly. (Some, yes; as you pointed out, if you can
burn things, you want to be able to extinguish them, too.) But mostly I
want to reduce the number of stub verbs (things that function in only one or
two places in the game and otherwise print a refusal message) in the
standard verb set. Compared to what you're suggesting that's a lowly goal,
but I think it will enable multiple-solution puzzles.
>As I said it's not only a matter of making modules slot into each other, you
>need to go to a level below that and develop a complete physical system,
>including collision checks, deformation checks (possibly with finite-element
>simulations), energy transformations, and ultimately even chemical
>reactions, and that would definitely be the end of palm-top IF, as you'd
Whoa, whoa. I think it's not useful to model objects past the point where
we can easily describe the results in words.
>need a lot of a modern computers cpu-power to evaluate the matrices that
>would result in. Actally it would go beyond IF completely, what we are
>talking about here is a step toward virtual reality computing.
No kidding. And it would be fun -- but let's recognize reality, here. 1)
existing languages aren't set up for this kind of thing; 2) text adventures
wouldn't describe the results well anyway; 3) other people who actually get
*paid* have already gone a significant distance towards solving some of the
relevant problems.
Thanks very much to the people who've told me about bugs in Peacock. It's
greatly appreciated.
ES
Sean T Barrett
>"Nicholas Shore" <nds.bl...@gmx.de> wrote:
>>E.g. I set fire to your sea-worn chest, and burnt the sheet of
>>paper that was lying on the panel to take the rubbing as well. When all I
>>had actually wanted was some ash to take the rubbing.
>
>envisioning would be inherently harder to close off than the traditional
>sort.
>
>I should implement "heap of ashes" as a result of burning, the way you get
>"shards of glass" when you break glass. But ash is one of those pesky
>objects that need a container to be carried around, which is why I've been
>putting it off until I have divisible liquids.
I posted recently about a mud I once worked on which had
a relatively sophisticated sense-based event description
system. We had implemented the beginnings of divisible
liquids--enough that you could do the "get 4 units of
liquid from a container of volume 3 and a container of
volume 5", using verbs like "fill with", "fill from",
"empty into". (Of course, as soon as you have divisible
liquids, you start running into the issue of mixable
liquids, which we didn't get to by the time we stopped.)
I mention this because things get pretty hairy when you
have objects reacting to each other. We used a pretty
naive queueing system for when objects to react to
the presence of other objects, and it resulted in the
following silly sequence of events (faux transcript
constructed from memory):
> INV
You're carrying a paper bag and a torch.
> LOOK IN BAG
In the bag is a rock.
> FILL BAG WITH WATER
You fill the bag with water from the barrel.
[Note: We hadn't gotten around to the notion that
a paper bag should get wet and probably fall apart.]
> LIGHT TORCH
You light the torch.
> PUT TORCH IN BAG
You put the torch in the bag.
The torch is extinguished by the water.
The bag catches fire from the torch.
>
The rock, the torch, and the water fall to the floor.
The bag turns to ash.
SeanB
Daryl McCullough
>I should implement "heap of ashes" as a result of burning, the way you get
>"shards of glass" when you break glass. But ash is one of those pesky
>objects that need a container to be carried around, which is why I've been
>putting it off until I have divisible liquids.
Have you gotten very far in this? I started to work on two
classes called Liquid and LiquidContainer (containers that
can hold liquids). The way that I worked it (in Inform) was
to simply give every LiquidContainer three properties, a liquid
(what liquid it currently contained), a level (how much it contained)
and a max-level (how much it could possibly contain). It was
necessary to implement rules for combining liquids (so that
putting water into the same container as wine would result in
dilute wine, rather than water or wine).
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Sean T Barrett
>Emily says...
>>I should implement "heap of ashes" as a result of burning, the way you get
>>"shards of glass" when you break glass. But ash is one of those pesky
>>objects that need a container to be carried around, which is why I've been
>>putting it off until I have divisible liquids.
>
>Have you gotten very far in this? I started to work on two
>classes called Liquid and LiquidContainer (containers that
>can hold liquids). The way that I worked it (in Inform) was
>to simply give every LiquidContainer three properties, a liquid
>(what liquid it currently contained), a level (how much it contained)
>and a max-level (how much it could possibly contain).
The way this was implemented (well, designed, 90% implemented)
on the mud I mentioned was without doing anything special for
the container (except marking whether it could hold liquids or
not); using a volume metric for all containership, including
liquids (so solids in the container reduce the amount of liquid
that can be in them), and making self-splitting liquid objects,
which would determine how much could fit, clone themselves into
two pieces, each of which was given the appropriate volume, one
piece of which was put in the container, and the rest of which
stayed behind for further processing.
If there was already some of a given kind of liquid in the container,
the two would notice each other (I think during the same processing
that handled getting things 'wet'), and merge back together. (This
was also the time when ideally two different bits of liquid would
decide whether they should mix into a new entity.)
Much of the sophistication actually needed to be handled in the
general notion of "moving a liquid". I've argued before for more
strongly separating the notion of parsing and world modelling--that
parsing should translate user input into small coherent actions
on the world.
To this end, "fill X from Y" meant "start moving things from Y
into X until X is full or Y is empty". "Empty X into Y" meant
"move things into Y until they no longer fit. Then move things
into Y momentarily (to get things wet/set on fire) and then
instead move into Y's parent". These two things were primitive
operations, not verbs, much like 'move object' in the first
place. If you want to force the player to drop everything,
you 'empty player into parent of player'. The command "fill X
with water" is not primitive but is handled by the parser, which
looks for accessible water and then generates a "fill X from Y"
command. There are problems with this, when, e.g. the container Y
has more than just water in it, but I still think it's the right
way to split things up.
I find it a very bad idea to put concepts in the wrong place--e.g.
"what liquid is in this container"? Far better to have an explicit
object that represents the liquid--for naming, addressability, etc.
SeanB
Emily Short
In article <87s9hn$2v...@edrn.newsguy.com>, da...@cogentex.com (Daryl
McCullough) wrote:
>Emily says...
>
>>I should implement "heap of ashes" as a result of burning, the way you get
>>"shards of glass" when you break glass. But ash is one of those pesky
>>objects that need a container to be carried around, which is why I've been
>>putting it off until I have divisible liquids.
>
>Have you gotten very far in this?
Fairly far. What I'm currently hung up on is the parse_name routine,
actually: the game can't distinguish between, eg, the wine in the green
bottle and the wine in the blue goblet, if the wines are otherwise the same.
So you can >DRINK WINE FROM GREEN BOTTLE but plain old >DRINK WINE creates
problems. (Yes, the game can ask the player to disambiguate, but nothing
the player can type will do this successfully until he modifies his syntax.
Deeply irritating. On the other hand, the last time I worked on this was
nearly six months ago, so I've had a lot more experience now with grammar
lines and parse_name. I think I should be able to find a workable solution
this time. I may wind up just assuming that liquid will always been in some
container, and force the player to use DRINK x FROM container, making a
default assumption about the container if only one is available.)
----------
In article <Fpoqn...@world.std.com>, buz...@world.std.com (Sean T
Barrett) wrote:
>The way this was implemented (well, designed, 90% implemented)
>on the mud I mentioned was without doing anything special for
>the container (except marking whether it could hold liquids or
>not); using a volume metric for all containership, including
>liquids (so solids in the container reduce the amount of liquid
>that can be in them), and making self-splitting liquid objects,
>which would determine how much could fit, clone themselves into
>two pieces, each of which was given the appropriate volume, one
>piece of which was put in the container, and the rest of which
>stayed behind for further processing.
Yes. That's what my system does -- except for the bit about solids in the
container reducing the liquid capacity. I'm going to deal with that, too;
in the interim I'm just refusing to allow the player to pour water into a
container that has something else in it. But that's petty and counter to
the spirit of this endeavor. I also want to distinguish things that float
from things that do not float. Since materials belong to their own classes
and can be assigned density, this shouldn't be too hard. (I'm trying to
avoid the use of attributes like floating vs ~floating, since this would
make it harder to implement, for instance, a buoyant salt solution.)
>If there was already some of a given kind of liquid in the container,
>the two would notice each other (I think during the same processing
>that handled getting things 'wet'), and merge back together. (This
>was also the time when ideally two different bits of liquid would
>decide whether they should mix into a new entity.)
When two liquids meet, a new item of class mixed_liquid is created, which
keeps track of what its components are and how much of each (so that a
mixture of 9 parts water to 1 wine can be distinguished from the reverse.)
Also, I've fixed "drink" so that it removes a semi-random amount of liquid.
(A sip is always within a certain volume range, but not always exactly the
same.) That way simply drinking liquid will not be viable as a measurement
technique.
This whole thing is still under development, or I would have put exempla
into Peacock. When game-crashing parser bugs started to drive me insane, I
stopped to work on my cut and burn routines. (And on other aspects of the
actual game that this all hypothetically belongs to.) I'm going back to the
liquids soon, though. Real Life permitting.
ES
Jon Ingold
>Have you gotten very far in this? I started to work on two
>classes called Liquid and LiquidContainer (containers that
>can hold liquids). The way that I worked it (in Inform) was
>to simply give every LiquidContainer three properties, a liquid
>(what liquid it currently contained), a level (how much it contained)
>necessary to implement rules for combining liquids (so that
>putting water into the same container as wine would result in
>dilute wine, rather than water or wine).
I found the most irritating thing to be the sheer number of ways the "Fill"
action can be generated. Things like
PUT WINE IN GOBLET
TRANSFER WINE TO BLUE GOBLET (which needs to work out where the wine is
coming from, since the parse replying "Do you mean the wine in the blue
goblet, or the wine in the green goblet would be very annoying)
EMPTY BLUE GOBLET INTO GREEN GOBLET
POUR WINE INTO BLUE GOBLET
FILL GOBLET WITH WINE
.. and so forth. (transfer is very irritating as I recall, though why
escapes me.)
Jon
Sean T Barrett
>The way this was implemented (well, designed, 90% implemented)
>on the mud I mentioned was without doing anything special for
>the container (except marking whether it could hold liquids or
>not); using a volume metric for all containership, including
>liquids (so solids in the container reduce the amount of liquid
>that can be in them), and making self-splitting liquid objects,
>which would determine how much could fit, clone themselves into
>two pieces, each of which was given the appropriate volume, one
>piece of which was put in the container, and the rest of which
>stayed behind for further processing.
Actually, I just looked at the code last night, and it was slightly
more subtle than this. There was a generic "mass object" type
which was used for continuously subdividable items (e.g. it
could have been used for bread or gold, although we never got
that far), and liquid inherited from that, liquid being a special
kind of mass object that subdivides without any significant effort.
One thing I can say from looking back at this code: man,
multiple inheritence is really convenient for inheriting
implementations of disparate functionality to synthesize
complex objects.
Unfortunately, one crucial file seems to be missing, or else
I'd roll up a PC executable for people to play with. Maybe
I'll make a pass through my 3.5" disks tonight and see if I
can find the missing stuff.
SeanB
JamesG
<several really big snips to keep this at a manageable length>
> 1. Don't bother to prevent the game from becoming unwinnable. Create a
> new game-play paradigm in which the player understands that burning
> something apparently harmless might be a bad idea. Also, make sure that
> you always provide "undo."
I like this idea - the traditional adventure game stresses the idea that
if something isn't nailed down, you should take it, if it's in you're
way you should break it, and if it's just sitting there you had better
do 'something' to it, just in case...
> 2. Have the game take note when you're about to remove from the game, eg,
> the last of the seven priceless objets d'art you could use to bribe the
> troll. This would be deeply annoying to program and would take away some of
> the fun of the openendedness. But then, I don't feel cheated if the game
> becomes unwinnable: I'm one of those insane players who save every ten moves
> and finish a game like Curses with over a megabyte of save files, all with
> inscrutable names like Cups139.
If there are multiple solutions to puzzles there are less unwinnable
situations. I need to get past the troll, and I've broken the last
object I could of used to bribe it? Well can I make a weapon (maybe
attaching a sharp shard of broken object d'art to a pole to make a
spear) and kill the troll? Can I turn off all the lights and wait for it
to be eaten by a grue? Can I distract the troll and sneak past it? Can
my beta-testers come up with 23 more potential solutions I hadn't even
considered?
> A neat twist would be if the game somehow kept track of *how* the player had
> solved various problems and used that information subtly to shape the player
> further. So if you had a player who was always smashing things in order to
> get to the end, the NPCs (or snarky parser comments) would treat the PC as a
> clod; whereas one employing Odyssean cunning would be regarded with respect.
> Or perhaps seen as a bit of a priss.
This is another really nice idea I'll keep in mind when I finally return
to my WiP.
JamesG,
and i will finish it some time...
--
Astrobiologist, Writer, Gamer, Cook.
This is not the sig you're looking for.
JamesG
>
> Yes. That's what my system does -- except for the bit about solids in the
> container reducing the liquid capacity. I'm going to deal with that, too;
> in the interim I'm just refusing to allow the player to pour water into a
> container that has something else in it. But that's petty and counter to
> the spirit of this endeavor. I also want to distinguish things that float
> from things that do not float. Since materials belong to their own classes
> and can be assigned density, this shouldn't be too hard. (I'm trying to
> avoid the use of attributes like floating vs ~floating, since this would
> make it harder to implement, for instance, a buoyant salt solution.)
Density is easy, as long as you already have weight and bulk properties
for items already (TADS does, I assume Inform has something similar),
assigning density as weight/bulk. It might require some playing around
to handle values <1 but it seems possible. Adding salt to water could
possibly be handled by using the pure water's bulk and summing the
weight of both (that might be over simplistic, it's a long time since I
did chemistry). As long as the game checks to see if anything already in
a liquid changes it's floating state it would allow puzzles like adding
salt to water to make an object float up. Object volumes allow
recreating the Aesop's fable of the crow, the pitcher and the stones,
though that one could get a little tedious...
>N, GET STONE, S, PUT STONE IN PITCHER
<repeat ad nauseam>
>DRINK
JamesG,
starting to feel a growing urge to code, but no time to do it in...
John E
There is a styrofoam block here.
>Throw foam in lake
(after taking it)
The block hits the water and floats.
>L
You are standing near a lake.
There is a styrofoam block on the lake (floating)
>stand on block
ok.. jokes aside.. if you did give everything a float atribute, how do you
use or implement floating?
> From: Mel Brittingham <brit...@america.net>
> Organization: 24hoursupport.com
> Newsgroups: rec.arts.int-fiction
> Date: Mon, 14 Feb 2000 23:55:32 -0500
> Subject: Re: Hard rocks, soft teddybears, fragile glass
>
> Emily Short wrote:
>
>> from things that do not float. Since materials belong to their own classes
>> and can be assigned density, this shouldn't be too hard. (I'm trying to
>> avoid the use of attributes like floating vs ~floating, since this would
>> make it harder to implement, for instance, a buoyant salt solution.)
>
> Yay! If you're gonna do it, you should do it right. (does this mean
> that instead of flammable you'll need temperature at which it burns and
> temperature at which it can catch fire?) :7
>
> Mel
Philip Goetz
news:87udnj$ab$1...@pegasus.csx.cam.ac.uk...
Agreed. This is why, when I wrote Inmate, I had all text input parsed
into a small number of primitive actions. "Get ball from gnome",
"Give ball to gnome", "Put ball in box", "Empty bucket [into current room]",
"Pour water into bucket", and so forth, all had the same underlying
representation. Some sort of transformational grammar or intermediate
representation is essential once you start getting into physical simulation.
(I never thought of any good way to combine liquids of different types.
As a first approximation, if you start with liquid A, and add a large amount
of liquid B, you should end up with something like liquid B -- if you add
an even larger amount of A, you should have something like A again.
Do you assign values instead of booleans to properties like "flammable",
and interpolate their values? So water mixed with gasoline has a
flammability
of .5? Or just keep track of how much of each type has gone into the mix?
Do the liquids layer? If you pour out from a bucket with oil & water,
does the oil come out first? What if you pull a plug from the bottom of the
bucket -- do you get water first?)
Phil Goetz