Time for an Inform Add-On Library?
FemaleDeer
Subject: Re: drudgery in IF creation?
From: mkku...@phylo.genetics.washington.edu (Mary K. Kuhner)
>Inform has pre-packaged solutions to some very common problems: for
>example, making an area light or dark, deciding if something can be
>eaten, putting something inside something else.
>I'd like to see more of these; there are some excruciatingly common
>problems that everyone seems to code up on their own. For example,
>defining liquids: the verb Drink and concept drinkable, the need for
>a container, pouring, spilling and so forth. NPCs who move on their
>own. Days and nights. Weight of objects. I'm slowly accumulating a
>little library of solutions to these problems, but it's a lot of work
>and the results don't impresss anyone, since everybody tackles these
>same problems.
This started me thinking...
When I coded in Pascal OOP, I brought an add-on OOP library. Using all the
Pascal OOP structures, the authors did the basic grunt work for you: screen
control, database managment, various date routines, dataentry forms,
reports, printer control. (Turbo Power, the company, did very well just
providing add-on libraries. I don't know how they are doing now that Pascal
is less popular, they moved from San Jose, CA. to Colorado).
If you use C you can buy all kinds of add-on libraries for screen control,
database managment, graphic control, terminal emulation, the list is endless.
I wonder why someone (Plotkin, Olsson, just to name two - I am sure quite
a few others could do it too) hasn't created an add-on Inform library?
Sure there are examples in Museum and Toyshop, very helpful examples. And
some of the stuff in the Christminister source code is masterful, but not
all complicated coding covers some of the simpler stuff (and liquids are
not simple).
I'd like to see something that had:
1. Various ways characters can be asked questions when objects are out of
scope (Graham and Rees) have both done this, but there could be even other ways.
2. Rope tying (or things like ropes). A single end tieable, both ends tieable.
3. Liquids, drinkable or otherwise. Containers that hold a liquid where
you can drink more than once before it disappears.
4. Fire, maybe with attributes like combustible and meltable and scorchable.
5. Drop in and drop over routines for the above and other situations.
(Drop in fire, drop in lake, drop over cliff.)
6. Climb up, climb down, expansion on climbing. And jump. (I am also
thinking of when the player is climbing across something.) More complicated
physical movement that does not entail just direction.
7. CutWith, AttackWith, etc. Expansion on existing verbs.
8. Question asking by NPCs and the player must respond either on the next
turn or within several turns. Because the question required an immediate answer.
9. Container enterable objects, that, when you close the door, you cannot
see the rest of the room.
10. A diagnose routine and a reasonable timer for the player to get hungry
or tired.
Those are just off the top of my head. I could think of even more. I am
sure you could too.
Good idea, huh?
Sorry, I can't do it, I am not a good enough programmer. But I am sure
some of us would be willing to pay. Routines that are able to be included
in our games with limited alteration. Just like that OOP library was, just
like other add-on libraries are.
Well, that's my wish. Now where is that star?
FD :-)
------------------------------------------------------------------------------
Femal...@aol.com The Tame Computer
"Loyalty to petrified opinion never yet broke a chain or
freed a human soul." Mark Twain (or won a game)
Andrew Plotkin
FemaleDeer (femal...@aol.com) wrote:
> >I'd like to see more of these; there are some excruciatingly common
> >problems that everyone seems to code up on their own. For example,
> >defining liquids: the verb Drink and concept drinkable, the need for
> >a container, pouring, spilling and so forth. NPCs who move on their
> >own. Days and nights. Weight of objects. I'm slowly accumulating a
> >little library of solutions to these problems, but it's a lot of work
> >and the results don't impresss anyone, since everybody tackles these
> >same problems.
> This started me thinking...
> I wonder why someone (Plotkin, Olsson, just to name two - I am sure quite
> a few others could do it too)
(Er, this is a completely trivial point, but I think it's slightly more
common Net-usage to refer to people by first and last name, rather than
just last name. Being referred to as "Andrew Plotkin" feels normal to me,
whereas just "Plotkin" feels curt and distant. I'm not pissed or
anything, just mentioning...)
(First name alone is fine too, but often not specific enough.)
> hasn't created an add-on Inform library?
> Sure there are examples in Museum and Toyshop, very helpful examples. And
> some of the stuff in the Christminister source code is masterful, but not
> all complicated coding covers some of the simpler stuff (and liquids are
> not simple).
Code snippets are usually better than a full library. These effects vary a
lot from game to game. And nobody is going to want to add them all at
once. You don't *want* an "attack X with Y" verb in a game which will
never use it; it's a distraction.
And yes, one of these days I'm going to write up a bunch of code snippets,
but I've got all this other stuff to do...
> 1. Various ways characters can be asked questions when objects are out of
> scope (Graham and Rees) have both done this, but there could be even
> other ways.
> 2. Rope tying (or things like ropes). A single end tieable, both ends tieable.
Everyone's favorite complicated example. A module which handled all
possible rope effects would be monstrous. Several specialized modules,
however, would be very useful.
> 3. Liquids, drinkable or otherwise. Containers that hold a liquid where
> you can drink more than once before it disappears.
Yup.
> 4. Fire, maybe with attributes like combustible and meltable and scorchable.
Don't forget the automatic "burn wood" "(with the torch)" inference. Of
course, I once thought about writing a game with several *types* of fire,
with different magical effects and different temperatures...
> 5. Drop in and drop over routines for the above and other situations.
> (Drop in fire, drop in lake, drop over cliff.)
The standard library already includes "drop in"; it maps to Insert, the
same as "put in".
> 6. Climb up, climb down, expansion on climbing. And jump. (I am also
> thinking of when the player is climbing across something.) More complicated
> physical movement that does not entail just direction.
This is the sort of thing which can already be achieved with a few lines
of code. You may want something like
Extend 'climb' first
* 'up' -> ClimbUp;
[ ClimbUpSub; <<Go u_obj>>; ];
> 7. CutWith, AttackWith, etc. Expansion on existing verbs.
That's what "Extend" is for.
> 8. Question asking by NPCs and the player must respond either on the next
> turn or within several turns. Because the question required an
> immediate answer.
Lo, the daemon... on the other hand, it's a nuisance to ensure that
"yes", "fred, yes", and "say yes to fred" all do the same. I've written
it about three times. That would be a good code snippet.
> 9. Container enterable objects, that, when you close the door, you cannot
> see the rest of the room.
I believe that the newest library handles this correctly.
> 10. A diagnose routine
This is the sort of thing which can't possibly be handled in a library;
the nature of injury is very game-specific, and so is the language which
will be used to describe it.
> a reasonable timer for the player to get hungry
> or tired.
Some people would say a reasonable hunger timer is one that doesn't run.
But then, some people would say it's not a taco without lettuce.
> Those are just off the top of my head. I could think of even more. I am
> sure you could too.
Doors. I sometimes dream of the morally correct Inform door class. Then I
wake up.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Giovanni Riccardi
FemaleDeer wrote:
>
> Subject: Re: drudgery in IF creation?
> From: mkku...@phylo.genetics.washington.edu (Mary K. Kuhner)
>
> >Inform has pre-packaged solutions to some very common problems: for
> >example, making an area light or dark, deciding if something can be
> >eaten, putting something inside something else.
>
> >problems that everyone seems to code up on their own. For example,
> >defining liquids: the verb Drink and concept drinkable, the need for
> >a container, pouring, spilling and so forth. NPCs who move on their
> >own. Days and nights. Weight of objects. I'm slowly accumulating a
> >little library of solutions to these problems, but it's a lot of work
> >and the results don't impresss anyone, since everybody tackles these
> >same problems.
I'm currently working on an Interactive Fiction Universal Library
(IFUL).
This comes as a part of my Visual Inform project (A Windows 95 IDE for
Inform).
Actually this project is still at the beginning due to my exams at
University and my Italian translation of Inform parser (the priority is
for this project).
Bye..
--
`'´
(O-O)
---oOO-- (_) --OOo------------------------------------
"How do you know I'm mad?"
said Alice. "You must be,"
Giovanni Riccardi said the Cat "or you
g.ric...@speednet.it wouldn't have come here."
Terracina Italy
- L. Carrol "Alice's
Adventures in Wonderland"
Visit P.O.V. Online, a place for your stories & poems:
http://www.geocities.com/Athens/Delphi/8758/index.html
------------------------------------------------------
FemaleDeer
>Er, this is a completely trivial point, but I think it's slightly more
>common Net-usage to refer to people by first and last name, rather than
>just last name. Being referred to as "Andrew Plotkin" feels normal to me,
>whereas just "Plotkin" feels curt and distant. I'm not pissed or
>anything, just mentioning...)
>
>(First name alone is fine too, but often not specific enough.)
>
Well, ANDREW, Z, Mr. Plotkin, seems like maybe I tickled your interest.
>Code snippets are usually better than a full library. These effects vary a
>lot from game to game. And nobody is going to want to add them all at
>once. You don't *want* an "attack X with Y" verb in a game which will
>never use it; it's a distraction.
Maybe you misunderstood me, a good add-on library, is code snippets, you
include only what you want. I mean a library as in the sense of a
collection of snippets. That the way Turbo power worked, you could only
call those routines that you wanted. True, all were included in a big
library but they worked it so that, memory wise, only what you called was
actually included. Inform, would have to be use more the actual "cut and
paste" approach, but it is the same idea.
>> 2. Rope tying (or things like ropes). A single end tieable, both ends
>tieable.
>
>Everyone's favorite complicated example. A module which handled all
>possible rope effects would be monstrous. Several specialized modules,
>however, would be very useful.
>
>> 3. Liquids, drinkable or otherwise. Containers that hold a liquid where
>> you can drink more than once before it disappears.
>
>Yup.
>
>> 4. Fire, maybe with attributes like combustible and meltable and
>scorchable.
>
>Don't forget the automatic "burn wood" "(with the torch)" inference. Of
>course, I once thought about writing a game with several *types* of fire,
>with different magical effects and different temperatures...
Any code snippets you or others want to share on some of the more basic
things that can happen in games, that the rest of us have to come up with
from scratch would be greatly appreciated.
If the idea is to make more IF and have more writers, than more snippets
would make that happen.
Inform is a great language but it has a very high learning curve. Writing
a simple game isn't too hard, but very soon the author probably gets into
unsimple areas and if you don't know Inform backwards and forwards it is
hard to do omplicated things while you are still learning it. These are the
kind of difficulties that can really "hang up" an author. And I suspect
that one could keep on learning new things about Inform for years (and years).
So I hope I peak your (and anyone else's) interest to share code snippets
on useful things with the rest of us. A, er, hum, LIBRARY of code snippets.
FD
Dan Shiovitz
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
[..]
>Doors. I sometimes dream of the morally correct Inform door class. Then I
>wake up.
Doors are another thing that simply can't be done properly with the
current IF paradigm. Since we have this idea of the "room" that
doesn't overlap with any other room, there's no way for an object to
be in two rooms at once. I don't know of a good way to fix this, short
of switching to a coordinate-based system.
>--Z
--
Dan Shiovitz :: scy...@u.washington.edu :: sh...@cs.washington.edu
..................................................................
"Alas, I do not rule the world and that, I am afraid, is the story
of my life: always a godmother, never a God." -- Fran Lebowitz
...http://weber.u.washington.edu/~scythe/home.html................
Neil K.
In article <5vf3av$p...@nntp5.u.washington.edu>, scy...@u.washington.edu
(Dan Shiovitz) wrote:
> Doors are another thing that simply can't be done properly with the
> current IF paradigm. Since we have this idea of the "room" that
> doesn't overlap with any other room, there's no way for an object to
> be in two rooms at once. I don't know of a good way to fix this, short
> of switching to a coordinate-based system.
You could have a single door object, then move it from either room as
necessary. I've done a slightly similar thing with an obstacle item in my
game. It's a kludge, but it can work. The reason I don't do it with doors
is because the current two-object door model supports assymetrical doors
automatically... doors which look/behave differently on either side.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Alan Conroy
On 13 Sep 1997 22:15:59 GMT, scy...@u.washington.edu (Dan Shiovitz)
wrote:
>Doors are another thing that simply can't be done properly with the
>current IF paradigm. Since we have this idea of the "room" that
>doesn't overlap with any other room, there's no way for an object to
>be in two rooms at once. I don't know of a good way to fix this, short
>of switching to a coordinate-based system.
(see my post elsewhere). This problem is NOT a problem with the
current IF paradigm. Adventure builder does not support/use
coordinate-based ANYTHING, but it does "properly" implement doors. I
imagine Inform could be enhanced to do something similar to Adventure
Builder (sorry to suggest more work for you Graham....)
- Alan Conroy
Andrew Plotkin
FemaleDeer (femal...@aol.com) wrote:
> Well, ANDREW, Z, Mr. Plotkin, seems like maybe I tickled your interest.
> Any code snippets you or others want to share on some of the more basic
> things that can happen in games, that the rest of us have to come up with
> from scratch would be greatly appreciated.
Heck, I was just throwing out some ideas myself. I've got a game to finish.
Andrew Plotkin
Dan Shiovitz (scy...@u.washington.edu) wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> [..]
> >Doors. I sometimes dream of the morally correct Inform door class. Then I
> >wake up.
> Doors are another thing that simply can't be done properly with the
> current IF paradigm. Since we have this idea of the "room" that
> doesn't overlap with any other room, there's no way for an object to
> be in two rooms at once. I don't know of a good way to fix this, short
> of switching to a coordinate-based system.
Well, the Inform library has always had a crude system for making objects
which *are* in two rooms at once. (In fact the objects are secretly moved
around behind the player's back, but it's a good enough hack.) And we've
long been using this trick to make two-sided doors.
What I really want, however, is to make two door objects that share a
single "open" flag -- or use a programmable rule for determining when
they're open. And which have programmable results for trying to walk
through -- when open, when closed, or according to some game-specific
system which has nothing to do with openness. (There's currently no
property you can set on a door to change the "You can't go that way,
because the door is in the way" message. Phooey!)
This is all possible in Inform. I've just never gotten around to putting
it all together into one set of classes.
Magnus Olsson
In article <19970913044...@ladder02.news.aol.com>,
FemaleDeer <femal...@aol.com> wrote:
>>Code snippets are usually better than a full library. These effects vary a
>>lot from game to game. And nobody is going to want to add them all at
>>once. You don't *want* an "attack X with Y" verb in a game which will
>>never use it; it's a distraction.
>
>Maybe you misunderstood me, a good add-on library, is code snippets, you
>include only what you want. I mean a library as in the sense of a
>collection of snippets.
There's some potential for confusion here. When you speak of just a
"library" in this context, it usually means a ready-made, "black box"
collection of functions (in C) or classes (in C++) with a well-defined
interface.
But the word "library" has many meanings, and one of them can certainly
be "library of code snippets".
Anyway, I tend to agree with you and Andrew that a collection of
example code is better than a "formal" class library. One reason is
that a library that is to be used as a black box needs a very
well-defined interface. Defining such an interface is probably more
work than most IF enthusiasts are willing to invest (it's one thing to
share one's nifty liquids code with other programmers, another to
spend a couple of weeks making sure the interface covers all possible
use cases).
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
FemaleDeer
>Heck, I was just throwing out some ideas myself. I've got a game to finish.
>
>--Z
Any code snippets you or anyone (Magnus, etc.) else doth want to share in
the future... of course you have a game to finish. But a "future projects"
list can grow... (and grow and grow).
Where did I get that word, doth, anyway?
Dan Shiovitz
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>Dan Shiovitz (scy...@u.washington.edu) wrote:
>> In article <erkyrathE...@netcom.com>,
>> Andrew Plotkin <erky...@netcom.com> wrote:
>> [..]
>> >Doors. I sometimes dream of the morally correct Inform door class. Then I
>> >wake up.
>
>> Doors are another thing that simply can't be done properly with the
>> current IF paradigm. Since we have this idea of the "room" that
>> doesn't overlap with any other room, there's no way for an object to
>> be in two rooms at once. I don't know of a good way to fix this, short
>> of switching to a coordinate-based system.
>
>Well, the Inform library has always had a crude system for making objects
>which *are* in two rooms at once. (In fact the objects are secretly moved
>around behind the player's back, but it's a good enough hack.) And we've
>long been using this trick to make two-sided doors.
Yeah, I know, but that's not "right" in some sense -- like you say,
it's a hack. This usually doesn't matter, but if I made a game with,
say, a scrying pool in it that let you look at any room in the world,
the standard door method wouldn't work.
One way to get around this might be to let rooms be contained in other
rooms. If you want rooms A and B to be connected by a door, put A and
B and the door all inside room C. That's not really a "neat" solution,
but it's a start.
>What I really want, however, is to make two door objects that share a
>single "open" flag -- or use a programmable rule for determining when
>they're open. And which have programmable results for trying to walk
>through -- when open, when closed, or according to some game-specific
>system which has nothing to do with openness. (There's currently no
>property you can set on a door to change the "You can't go that way,
>because the door is in the way" message. Phooey!)
It might be nice to have this as a language extension, some sort of
way to "share" variables between objects so that the variables always
have the same value. Something like static class members in C++.
>This is all possible in Inform. I've just never gotten around to putting
>it all together into one set of classes.
>
>--Z
--
Jeff Hatch
Dan Shiovitz wrote:
> Doors are another thing that simply can't be done properly with the
> current IF paradigm. Since we have this idea of the "room" that
> doesn't overlap with any other room, there's no way for an object to
> be in two rooms at once. I don't know of a good way to fix this, short
> of switching to a coordinate-based system.
I haven't written a full library for my new IF authoring system yet, but
doors are already easy. I have a generic "Item" class with an
overrideable "MatchLocation" function. The "Obstacle" class overrides
the MatchLocation function to make sure that any Obstacle object you
create (such as a door) will be visible in both of the two locations
that it connects.
Very easy to do, and I assume that the Inform library could be modified
to allow something similar. Making two doors is a lot of unnecessary
work, and kludging the problem with a teleporting door could have some
irritating side-effects if actors other than the player can interact
with that door.
-Rúmil
Andrew Plotkin
Dan Shiovitz (scy...@u.washington.edu) wrote:
> >What I really want, however, is to make two door objects that share a
> >single "open" flag -- or use a programmable rule for determining when
> >they're open.
> It might be nice to have this as a language extension, some sort of
> way to "share" variables between objects so that the variables always
> have the same value. Something like static class members in C++.
Sheesh, language extensions. What's wrong with obj.setopen(val) and
obj.isopen()? If you're going to throw away the use of "open" as an
attribute (which you'd have to, since the Z-machine won't allow shared
attributes no matter what language is used) you should go to property
execution.
A language feature for shared variables handles exactly one case: a set
of objects which are constrained to be all open or all closed.
setopen() and isopen() handle that plus all the other cases. Airlock
doors that are always in *different* states; doors which are open based
on a puzzle solution or the player's location; etc.
I suppose one could diddle Inform so that the "give obj open" and "obj
has open" constructs generated setopen() and isopen() calls, with the
default implementation of
Object
with
setopen [ val;
self.open = val;
],
isopen [;
return (self.open);
];
(note that "open" is now a property, and Z-machine attributes are not
involved at all.)
But this is radical; it's probably better to make the programmer switch
to the different syntax, since it's really a new system. And then you
don't have to change the language.
(Footnote: ok, actually obj.setattr(open, val) and obj.hasattr(open). If
you don't understand why, don't worry about it.)
Graham Nelson
>
> (There's currently no
> property you can set on a door to change the "You can't go that way,
> because the door is in the way" message. Phooey!)
Not wishing to quibble, but
door_to "You can't go that way, because even though Andrew
thinks it's impossible, there is some more subtle
than usual reason why not. Phooey!"
ought to do the trick?
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Stephen van Egmond
There is the library contributions section of the inform6 library. You
can see the contents, with links to the if-archive, here:
There's money, clocks, sensible time input, elevators, and menu-based
conversation style, among others. Though, oddly, none of the things FD
mentioned.
(Or is that why you mentioned them...)
/Steve
Andrew Plotkin
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin
> <URL:mailto:erky...@netcom.com> wrote:
> >
> > (There's currently no
> > property you can set on a door to change the "You can't go that way,
> > because the door is in the way" message. Phooey!)
> Not wishing to quibble, but
> door_to "You can't go that way, because even though Andrew
> thinks it's impossible, there is some more subtle
> than usual reason why not. Phooey!"
> ought to do the trick?
Oops, sorry. Probably that works. (I say "probably" only because I
haven't tried it.)
I have lingering paranoia about door_to, from the "transport to object
Class" bug in library 6/5. Please ignore.
Paul Francis Gilbert
femal...@aol.com (FemaleDeer) writes:
A library of code snippets would be a fantastic idea. Especially if it were
on the Internet. I know Borland are considering adding an online code
snippet library for Delphi, where Delphi programmers can submit code
snippets via the web, and view snippets.
An online code snippet library for TADS, Inform, and Hugo [as the three most
popular languages], would be a great idea. I know some of the IF web pages
have some short lists of example code already, we could centralise it all into
a central repository. As far as I can see, it would help promote better
programming if the novices have expert code snippets available, and only lead
to better IF programming overall.
--
Paul Gilbert | p...@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
Tim Hamilton
FemaleDeer wrote:
> Where did I get that word, doth, anyway?
Ithn't it what computerth ran on before Windowth ? Betht Thythem for
running tektht adventureth with ?
I apologise, I could resist that. I'll go now. :)
--
Tim Hamilton ti...@yarranet.net.au Yarranet
FROBOZZ SOUTH MAGIC SCROLL COMPANY CATALOGUE NUMBER #724C/M
ERDWAD - Stop the tap from dripping.
Incorrigible Punster - Please do not incorrige me any further.
Tim Hamilton
Magnus Olsson wrote:
> There's some potential for confusion here. When you speak of just a
> "library" in this context, it usually means a ready-made, "black box"
> collection of functions (in C) or classes (in C++) with a well-defined
> interface.
>
> But the word "library" has many meanings, and one of them can certainly
> be "library of code snippets".
Actually, sometimes, that's what the black boxes could mean. I might be
misunderstanding you, but I thought a black box is something that you
can trust to behave in a very specific way (If this is what you were
referring to by interface, then its my error). The name black box
springs from the idea that you can't see how it goes about it's work,
you just trust it to return an expected variable or make an expected
action. An example (Inform-wise), of this might be a torch and the light
command. Most people don't know how it works within the code, but just
expect that once the command has been sent, the torch object will have
the light attribute set correctly.
This could be good in certain situations, for example, where you need
the code snippet without editing, other than what is required to fit in
it into your own program. A lantern object for instance, that only
requires to be told how many turns it's light will last for. You could
almost put that in a library and forget about it.
On the other hand, a glass box (a black-box's opposite), in the same
situation would be handy for someone who wanted the lantern to be a
flaming torch, and therefore react to the environment the way a naked
flame should where a covered flame wouldn't. Like, enetering an area
filled with flammable gas.
> work than most IF enthusiasts are willing to invest (it's one thing to
> share one's nifty liquids code with other programmers, another to
> spend a couple of weeks making sure the interface covers all possible
> use cases).
Umm, thinking of that, how about a library of superclasses for example ?
A bunch of items that might behave in pre-defined ways. (ie torch,
clothing, door (already done really I guess in Inform), vehicle, etc.)
Vehicle car
with ......
and already assume that by giving the object class Vehicle, that it has
the attributes and basic movement rules set.
Anyhow, my 2 cents...
--
Tim Hamilton ti...@yarranet.net.au Yarranet
FROBOZZ SOUTH MAGIC SCROLL COMPANY CATALOGUE NUMBER #766TR/D
SHAGAS - Remove spinach from teeth.
FemaleDeer
>Subject: Re: Time for an Inform Add-On Library?
>From: svan...@undergrad.math.uwaterloo.ca (Stephen van Egmond)
>Date: Mon, 15 Sep 1997 15:33:18 GMT
>Steve
Observant of you. :-)
I feel sometimes people like to show off their ability to do complicated
code, but often it is the simplier things (or the things that could only be
code snippets, not a whole add-on "*.h" file or a program) that hang us new
authors up.
If I see an example of something, I can take it from there, I suppose that
is the way most of us are.
Magnus Olsson
In article <341E039E...@yarranet.net.au>,
Tim Hamilton <ti...@yarranet.net.au> wrote:
>Magnus Olsson wrote:
>> There's some potential for confusion here. When you speak of just a
>> "library" in this context, it usually means a ready-made, "black box"
>> collection of functions (in C) or classes (in C++) with a well-defined
>> interface.
>>
>> But the word "library" has many meanings, and one of them can certainly
>> be "library of code snippets".
>
>Actually, sometimes, that's what the black boxes could mean. I might be
>misunderstanding you, but I thought a black box is something that you
>can trust to behave in a very specific way (If this is what you were
>referring to by interface, then its my error). The name black box
>springs from the idea that you can't see how it goes about it's work,
>you just trust it to return an expected variable or make an expected
>action.
The point here is that you *can't* see into a black box. In a library
of code snippets, you can see into the "boxes". You can of course choose
not tolook into them, even if they are transparent :-).
To me, the notion of a "library of code snippets" means a library
of code that you can cut and paste into your own application, and that
may (and probably will) need some hacking to interface to your code.
In contrast, a traditional function or class library presents you with
a set of black boxes and a fixed API (application program
interface). Although source code is sometimes suppliedou're not
supposed to have to modify it.
To be more concrete: the solutions to Graham's exercises in the Manual
are code snippets that you can sometimes use as is but that you'll
usually have to modify to make them work with your program. They're
not intended to be perfectly general, just ot be general enough for
you to build on (sorry if I've misrepresented your intentions,
Graham). The Inform Library, on the other hand, is more of a "black
box" - you're not really supposed to have to hack around inside
it. The fact that many of us *have* had to hack the library is in some
sense a sign of failure to make it a good black box. The fact that
Graham didn't quite succeed in making it a black box shows how
difficult such a task is. :-)
> An example (Inform-wise), of this might be a torch and the light
>command. Most people don't know how it works within the code, but just
>expect that once the command has been sent, the torch object will have
>the light attribute set correctly.
In a "black box" library, such a torch class would have to be made
sufficiently general that it cover most uses, and that modified uses
could be achieved by inheriting from the torch class, rather than
modifying the class itself.
In a "library of code snippets", there would be code for implementing
a torch, with comments telling you how to modify that code if you
want a different behaviour.
See the difference?
>Umm, thinking of that, how about a library of superclasses for example ?
>A bunch of items that might behave in pre-defined ways. (ie torch,
>clothing, door (already done really I guess in Inform), vehicle, etc.)
>
>Vehicle car
> with ......
>
>and already assume that by giving the object class Vehicle, that it has
>the attributes and basic movement rules set.
This is what is usually called a class library, and in OO systems it's
the preferred way of extending the system. The classes could be
made as "black boxes" or as "code snippets".
Dragonslayer
Jeff Hatch <jeff...@juno.com> wrote:
>Very easy to do, and I assume that the Inform library could be modified
>to allow something similar. Making two doors is a lot of unnecessary
>work, and kludging the problem with a teleporting door could have some
>irritating side-effects if actors other than the player can interact
>with that door.
Speaking of which...
How about this alternative to found_in and floating objects and all that: say that you have
a class called Floater which has no properties and exists for the sole purpose of being
ofclass-able in an objectloop. Furthermore, say that you defined subclasses of Floater
that would allow multiple instances of themselves to be created (as many as there are actors).
Also say that MoveFloatingObjects has been modified to create instances of your Floater
subclasses and move them around based on the contents of their found_in properties and
the locations of the actors.
I mention this because I am writing a more NPC-friendly version of VerbLib, and I am currently
dealing with this very problem. What do you think? Is there an easier way to do this?
/------------------------------------------------------\
| Dragonslayer dragon...@mad.scientist.com |
| |
| "Gentlemen, we can rebuild him. We have the masonry." |
| -Feet of Clay |
\------------------------------------------------------/
Andrew Plotkin
Andrew Plotkin (erky...@netcom.com) wrote:
> Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> > In article <erkyrathE...@netcom.com>, Andrew Plotkin
> > <URL:mailto:erky...@netcom.com> wrote:
> > >
> > > (There's currently no
> > > property you can set on a door to change the "You can't go that way,
> > > because the door is in the way" message. Phooey!)
> > Not wishing to quibble, but
> > door_to "You can't go that way, because even though Andrew
> > thinks it's impossible, there is some more subtle
> > than usual reason why not. Phooey!"
> > ought to do the trick?
> Oops, sorry. Probably that works. (I say "probably" only because I
> haven't tried it.)
Update: no, it doesn't work. The door_to property is only checked if the
door is *open*. If the door is closed, the library prints "You can't go
that way, because the door is in the way" before door_to is ever called.
Doesn't have to be a subtle reason, by the way. I just like to be able to
put in messages like "You can't walk through a closed steel door, you
idiot."
You can achieve this effect by putting in a before:Go clause in the room,
or a react_before:Go clause on the door. There's nothing wrong with this,
but in my dream door library, this message comes from a door property and
not an action trap. Just a preference.
Jeff Laing
FemaleDeer wrote:
> I wonder why someone (Plotkin, Olsson, just to name two - I am sure quite
> a few others could do it too) hasn't created an add-on Inform library?
I tried doing something like this for TADS, way back when I was actively
working on my Zork port. I deliberately made myself build reusable
classes
(which are in jeffslib.zip on ftp.gmd.de somewhere) so that the
community
would benefit.
As a result, I made the whole exercise overwhelmningly difficult and
eventually gave up. In all the time its been there, I saw precisely one
piece of feedback about it all which, fortunately, was someone who had
taken the ideas + code and built on them, and made the available again.
Building a library is a difficult task, as Neil pointed out in a
previous
message because you need to think of all possible combinations, not just
those that apply to your game.
And I fear that, like O-O-programming in general, whilst people believe
in the principal of reuse, under the covers most of us are programmers
who want to be authors and programmers typically want to reinvent rather
than reuse. Why else would we continually discuss inventing new
"systems"
when the real problem is lack of "games".
( sits back and waits for flames :-)
Jeff.
JC
On 14 Sep 1997 20:57:41 GMT, scy...@u.washington.edu (Dan Shiovitz) wrote:
[...]
>One way to get around this might be to let rooms be contained in other
>rooms. If you want rooms A and B to be connected by a door, put A and
>B and the door all inside room C. That's not really a "neat" solution,
>but it's a start.
I'm not sure what you'd have to do for the door thing, but WorldClass
allows you to have rooms contained in other rooms, by using the Connection
Class. A connection room is one that can contain other rooms, so you can
connect locations within it "so that objects and senses available in one
room become available in the other(s)" (taken from the WorldClass manual).
[...]
FemaleDeer
>And I fear that, like O-O-programming in general, whilst people believe
>in the principal of reuse, under the covers most of us are programmers
>who want to be authors and programmers typically want to reinvent rather
>than reuse. Why else would we continually discuss inventing new
>"systems"
>when the real problem is lack of "games".
>
>( sits back and waits for flames :-)
>
>Jeff.
My point exactly. :-) Share the weath, don't hoard. But you said it so
much better. As a programmer, I actually prefer reuse rather than reinvent,
I am not out to prove what a great programmer I am (maybe because I am not).
I don't see why we have to keep reinventing the wheel, and sharing more
code (snippets of code) would help new authors more than anything else
anyone could do.
I am deeply indebited to Garth Rees for sharing the source to
Christminister and to Graham Nelson for Balances, Museum and Toyshop's
source. I could never have figured out somethings (well, not in a
reasonable length of time) without using them as examples (I also lifted
out some parts complete).
I still would like to see the code of someone more brilliant than I for
that list of routines etc. that I gave. How would someone else handle a
rope that ties at both ends? My code usually looks like spagetti for
problems like that.