[Inform] OO library
Michael Gentry
knowledge) has offered any specific examples of what that would mean. This
is one idea I've had for a while, and I really wish I knew enough about
programming to make it happen. I'd be interested to hear what some of the
more tech-knowledgable gurus think would or wouldn't work about it.
My one-item wish-list:
I would like verbs to be objects. It seems to me that, instead of verbs
being disconnected routines, they would look more like this:
Verb Foo with
perform [....];
Then, when you want to call a verb in your program, instead of typing:
<<Foo lantern>>;
you would type
Foo.perform (lantern);
rtrue;
It seems like this would allow some flexibility that Inform doesn't
currently allow (or at least make easy).
For example, you could make subclasses of verbs.specifically, I was thinking
how you could make a "Moving" class for verbs that require use of your
limbs, and you could disallow those verbs under certain conditions by
testing for that class (the handcuffs, dangling rope, and straight jacket in
my game would have been MUCH easier with something like this.) You could
make a "Touching" class for verbs that implies you physically handling the
object -- these verbs would automatically run an IsItTouchable property
(which would be inherited, so you only have to type it once) to see if the
object in question is within reach.
(Yeah, I know there's an IsItTouchable routine already, but about 85% of the
verbs that should use it, don't.)
You could assign attributes to verbs. You could flag the first time a player
types a verb -- any verb -- regardless of what the player performs the verb
on. You could assign a number property to verbs, to keep track of how many
times the player performs each one.
Here's a puzzler: I made "inventory" a meta-verb in Anchorhead, because
people kept having to check their inventories during tightly-timed puzzles.
But in doing so, I had to remove the grammar TAKE INVENTORY, because you
can't label only *one* line of the Take grammar as meta. If, instead of
labeling a group of grammar lines, I could have assigned a "meta" attribute
to the Inventory verb itself, it would have saved me some trouble.
So, hit me: what's wrong with this idea, and how hard would it be to
implement it?
-M.
================================================
"If you don't eat your meat, you can't have any pudding.
How can you have any pudding if you don't eat your meat?"
Doeadeer3
In article <736sk0$e...@journal.concentric.net>, "Michael Gentry"
<edr...@concentric.net> writes:
>I would like verbs to be objects. It seems to me that, instead of verbs
>being disconnected routines, they would look more like this:
>
>Verb Foo with
> perform [....];
>
>Then, when you want to call a verb in your program, instead of typing:
> <<Foo lantern>>;
>you would type
> Foo.perform (lantern);
> rtrue;
>
>It seems like this would allow some flexibility that Inform doesn't
>currently allow (or at least make easy).
Yes, I agree whole heartedly. If VerbSubs could be changed into objects it
would greatly increase Inform's flexibility. It would also, to my way of
thinking, make how verbs work much more consistent. Which would be a big
improvement.
In fact, when I envision an OO Library that IS the major improvement I see.
>For example, you could make subclasses of verbs.specifically, I was thinking
>how you could make a "Moving" class for verbs that require use of your
>limbs, and you could disallow those verbs under certain conditions by
>testing for that class (the handcuffs, dangling rope, and straight jacket in
>my game would have been MUCH easier with something like this.) You could
>make a "Touching" class for verbs that implies you physically handling the
>object -- these verbs would automatically run an IsItTouchable property
>(which would be inherited, so you only have to type it once) to see if the
>object in question is within reach.
How to do it is where I fall down. Although the above are good ideas. I have
also thought of a superclass for verbs that have a before and after and a
superclass for verbs that have no after. Two slightly different behaviors.
On the whole, you appear to be further along in your thinking about it than I
and I will have reread your post several times to "get" it.
I think a lot of people don't realize how OO could make the library more
useable, not less. I have used third party libraries (mainly for Borland
Pascal) that were all OO and once one understands the overall concept, one
finds they are EASIER to add on to, thus, change/alter for one's own use.
It would be a h*ll of a lot of work to rewrite Inform's library that way,
though.
I will reread your post several times.
Doe :-)
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
e...@uclink4.berkeley.edu
> People have been tossing around the idea of an OO library, but no-one (to my
> knowledge) has offered any specific examples of what that would mean. This
> is one idea I've had for a while, and I really wish I knew enough about
> programming to make it happen. I'd be interested to hear what some of the
> more tech-knowledgable gurus think would or wouldn't work about it.
> My one-item wish-list:
> I would like verbs to be objects. It seems to me that, instead of verbs
> being disconnected routines, they would look more like this:
> Verb Foo with
> perform [....];
> Then, when you want to call a verb in your program, instead of typing:
> <<Foo lantern>>;
> you would type
> Foo.perform (lantern);
> rtrue;
> It seems like this would allow some flexibility that Inform doesn't
> currently allow (or at least make easy).
> For example, you could make subclasses of verbs.specifically, I was thinking
> how you could make a "Moving" class for verbs that require use of your
> limbs, and you could disallow those verbs under certain conditions by
> testing for that class (the handcuffs, dangling rope, and straight jacket in
> my game would have been MUCH easier with something like this.) You could
> make a "Touching" class for verbs that implies you physically handling the
> object -- these verbs would automatically run an IsItTouchable property
> (which would be inherited, so you only have to type it once) to see if the
> object in question is within reach.
> (Yeah, I know there's an IsItTouchable routine already, but about 85% of the
> verbs that should use it, don't.)
> You could assign attributes to verbs. You could flag the first time a player
> types a verb -- any verb -- regardless of what the player performs the verb
> on. You could assign a number property to verbs, to keep track of how many
> times the player performs each one.
> Here's a puzzler: I made "inventory" a meta-verb in Anchorhead, because
> people kept having to check their inventories during tightly-timed puzzles.
> But in doing so, I had to remove the grammar TAKE INVENTORY, because you
> can't label only *one* line of the Take grammar as meta. If, instead of
> labeling a group of grammar lines, I could have assigned a "meta" attribute
> to the Inventory verb itself, it would have saved me some trouble.
> So, hit me: what's wrong with this idea, and how hard would it be to
> implement it?
I have been thinking of these things quite a lot, since I'm writing an
OO library for Inform. What I have know is as follows:
Each verb is an object. They're of the class Verb. They have some properties;
notable imperative (a list of words that can be used as the verb) and
adverb (a list of adverbs). Ideally, I'd like to have a parse routine
that could parse things by hand, if need be. So we have verbs like:
Verb inventory
with imperative 'take' 'inventory',
adverb 'inventory';
So this will match 'take inventory' and 'inventory' and 'take'; which
I need to fix. :)
The tricky part is how is the verb handled? Some verbs should be handled
by that very object; like save and quit. Others, like take, push, etc. need
to be handled by the objects being taken, or pushed. So one calls
actions like this:
actor.makeact (verb, direct-object, indirect-object, prepositional-object,
sense);
All of which are optional.
This makes the actor do the thing. The makeact routine calls various
perform functions, which actually do the work. Then it propogates
sensory information to objects who can see (or hear, or feel, or whatever)
the action. An empty action is just a way of informing sensors
that the object is still there.
I'm not sure yet how to handle scope for things like isTouchable.
I have a system of different scopes, but I'm not sure it's the best.
I think perhaps a good thing would be to have each verb object
have an "inDoScope" routine which would return true of false
if the object passed to it were in it's scope. It might
make things very slow, though.
Any ideas, folks? :)
Doeadeer3
>a "Touching" class for verbs that implies you physically handling the
>object -- these verbs would automatically run an IsItTouchable property
>(which would be inherited, so you only have to type it once) to see if the
>object in question is within reach.
>
>(Yeah, I know there's an IsItTouchable routine already, but about 85% of the
>verbs that should use it, don't.)
Moving, maybe, depends how doors are done. Touchable, yes, if I take you to
mean take, remove, etc. actions that require a touch action. Then the
programmer/writer could hook in an out of reach class to that (hehehe).
>You could assign attributes to verbs. You could flag the first time a player
>types a verb -- any verb -- regardless of what the player performs the verb
>on. You could assign a number property to verbs, to keep track of how many
>times the player performs each one.
Hmm, might be handy, but I think a verb counter for a verb wouldn't be
necessary for a "standard" library, that is an addition the programmer could
easily do themselves.
As Z has said (oh, drat, I am quoting Z) the good thing about the library is IT
is general, it doesn't attempt to cover every instance (well, actually I am NOT
quoting Z, because he said it better) and I agree with that.
An OO library should still be a general library. But making it OO would
automatically make it more "hookable" for whatever else the author wants to
add.
Michael Gentry
Doeadeer3 wrote in message <19981121174537...@ngol08.aol.com>...
>
>In article <736sk0$e...@journal.concentric.net>, "Michael Gentry"
><edr...@concentric.net> writes:
>
>Moving, maybe, depends how doors are done. Touchable, yes, if I take you to
>mean take, remove, etc. actions that require a touch action. Then the
>programmer/writer could hook in an out of reach class to that (hehehe).
I didn't say verbs that move you from room to room; I said verbs that
require you to move your limbs. Thus verbs like Examine, Smell, Listen, Say,
Ask, and Tell could be distinguished from verbs like Go, Take, Open, Push,
WaveHands, etc.
>Hmm, might be handy, but I think a verb counter for a verb wouldn't be
>necessary for a "standard" library, that is an addition the programmer
could
>easily do themselves.
Of course. Right now, it's not easy to do myself.
Doeadeer3
In article <737gp0$5...@journal.concentric.net>, "Michael Gentry"
<edr...@concentric.net> writes:
>I didn't say verbs that move you from room to room; I said verbs that
>require you to move your limbs. Thus verbs like Examine, Smell, Listen, Say,
>Ask, and Tell could be distinguished from verbs like Go, Take, Open, Push,
>WaveHands, etc.
Okay, I didn't read it carefully enough. Don't hit me. ;-) Thinking how to make
it OO is kinda difficult and you have gotten farther with it than I. I get your
drift... check whether the player can move before doing a move action and Go
would occur before door checking anyway.
On that basis, sounds good.
Doeadeer3
In article <c0f737...@raisin.hip.berkeley.edu>, e...@uclink4.berkeley.edu
writes:
>The tricky part is how is the verb handled? Some verbs should be handled
>by that very object; like save and quit. Others, like take, push, etc. need
>to be handled by the objects being taken, or pushed. So one calls
>actions like this:
>
>actor.makeact (verb, direct-object, indirect-object, prepositional-object,
> sense);
>
>All of which are optional.
>
>This makes the actor do the thing. The makeact routine calls various
>perform functions, which actually do the work. Then it propogates
>sensory information to objects who can see (or hear, or feel, or whatever)
>the action. An empty action is just a way of informing sensors
>that the object is still there.
Basically, that is similar to how I envision it.
All the actions are under the top object or top class of the actor, because the
actor is the originator of said actions. The verb objects themselves then call
the before and/or after of the takeable (etc.) object.
The actually actions performed are in each verb object, So Isuntouchable or
something like that would belong there or in a metaclass for verbs.
This is strictly off the top of my head because I have not thought about it a
lot.
Actor Class (PC and NPCs)
call verb with object
MetaVerb Class
IsUntouchable
IsMovable
Etc. whatever one wants to add
AfterBefore Verb Class
call Meta class with object
call object's before rtrue or rfalse
perform action
call object's after
BeforeVerbClass
call Meta class with object
call object's before rtrue or rfalse
perform action
Object
before respond to call
after respond to call
Of course, I really know diddly about actually writing an OO library.
Did I understand you correctly?
Jonadab the Unsightly One
> So, hit me: what's wrong with this idea,
That little thing about breaking existing code, for one.
> and how hard would it be to
> implement it?
I think the parser is among the existing code that
would get broken...
--
BTW there is a workaround for making one action meta
when other actions from the same verb word aren't,
but it's not straightforward.
- jonadab
Doeadeer3
In article <365727f7...@news.bright.net>, jon...@zerospam.com (Jonadab
the Unsightly One) writes:
>I think the parser is among the existing code that
>would get broken...
The whole library would have to be written OO, which includes the parser, of
course. It could stay the same essentially, but it would have to use the new
phraselogy. Which is partially why it would be a lot of work to rewrite the
library to be OO.
Not impossible, but a LOT of work.
e...@uclink4.berkeley.edu
I think so. :) I have a more general view of things, I think. Like this.
Animate class
send a perform message to object(s)
figure out who to inform of the action [sensors, animates, etc.]
send a sense message to [sensors, aniamtes, etc.]
Player class
on sense message
call generate message
Thing
on perform message
do something useful (more objects, change them, etc.)
return a value (number or string)
on generate message
print natural language information
I have combined before/after/during into perform/sense/generate.
Perform does something. The sense message is for sensors, animates,
players, etc. It is the method by which an object learns what is happening.
If that object is a player, it makes sense (no pun intended) to
print out a natural language statement of what has happened. If
the perform message has returned a string, it prints that string.
Otherwise, the object that /performed/ the action has its generate
method called. This generate method prints out the message.
If the sensor is instead, say, an alarm, it might go off. If it
is a remote controlled device and the action was the pressing of
a button, it might turn on. And so forth.
I'm not sure how to fit isUntouchable (are we to have a system of castes
as well as classes? perhaps we need isBrahmin, etc. :) into all of this.
Any ideas? (In fact, I need to reread these messages and find out what
is desired/needed).
--
Erik Hetzner <e...@uclink4.berkeley.edu>
Jonadab the Unsightly One
> Verb inventory
> with imperative 'take' 'inventory',
> adverb 'inventory';
>
> So this will match 'take inventory' and 'inventory' and 'take'; which
> I need to fix. :)
While it will break all existing code, I can see value in turning the
verbs into objects in an alternative library.
But Inform's grammar as it sits is *so* flexible that to
change it to the above horridly inflexible system
seems intollerable. My take would be to have
the grammar lines stay the way they are, except
that instead of mapping to FooSub you map to the
object Foo of class Verb.
Seriously, how would a verb object handle
things like one verb word referring to different
verbs depending on the direct object token
matched? How would you handle the
scope= token, the noun= token, or the
routine token? I just don't see it. Grammar
is Inform's shining strong point the way it
is now.
- jonadab
Jonadab the Unsightly One
> The whole library would have to be written OO,
Exactly.
> which includes the parser, of course.
You go right ahead.
> It could stay the same essentially, but it would have to use the new
> phraselogy. Which is partially why it would be a lot of work to rewrite the
> library to be OO.
>
> Not impossible, but a LOT of work.
Then, when you're done, you have the Inform
equivalent of Worldclass -- an ostensibly better
library that you still have to convince anybody
to start using, considering that they basically
have to completely relearn everything.
- jonadab
George Caswell
> doea...@aol.com (Doeadeer3) wrote:
>
> > The whole library would have to be written OO,
> > It could stay the same essentially, but it would have to use the new
> > phraselogy. Which is partially why it would be a lot of work to rewrite the
> > library to be OO.
> >
> > Not impossible, but a LOT of work.
>
> Then, when you're done, you have the Inform
> equivalent of Worldclass -- an ostensibly better
> library that you still have to convince anybody
> to start using, considering that they basically
> have to completely relearn everything.
>
I'm not convinced that it would be any better fundamentally. You're still
designing the library around the severely limited VM. There's nothing wrong
with that-- in fact, if it weren't for the severely limited VM I wouldn't be
able to play all these great games on my Pilot. The thing is, just making the
library object-oriented doesn't accomplish anything. I think a better
contribution to IF libraries might be, perhaps, practical application of some
AI approaches- most of which would be beyond the scope of your average
Z-machine, for the simple reason that there's not a whole lot of space in
there to throw around for problem solving strategies and redundant
representations and the like. Of course, authors would need to understand
that stuff to use it properly...
Either way, I don't see rewriting the Inform library as substantial
progress, really. If you're going to do all that work you may as well apply
it to something a little more interesting.
---GEC
"I see a great hand, reaching out of the stars... it is your hand...
I hear things.. I hear millions of voices calling out your name..."
"My followers?"
"Your victims."
Erik George Hetzner
: On Tue, 24 Nov 1998, Jonadab the Unsightly One wrote:
:> Then, when you're done, you have the Inform
:> equivalent of Worldclass -- an ostensibly better
:> library that you still have to convince anybody
:> to start using, considering that they basically
:> have to completely relearn everything.
:>
: I'm not convinced that it would be any better fundamentally. You're still
: designing the library around the severely limited VM. There's nothing wrong
: with that-- in fact, if it weren't for the severely limited VM I wouldn't be
: able to play all these great games on my Pilot. The thing is, just making the
: library object-oriented doesn't accomplish anything. I think a better
: contribution to IF libraries might be, perhaps, practical application of some
: AI approaches- most of which would be beyond the scope of your average
: Z-machine, for the simple reason that there's not a whole lot of space in
: there to throw around for problem solving strategies and redundant
: representations and the like. Of course, authors would need to understand
: that stuff to use it properly...
: Either way, I don't see rewriting the Inform library as substantial
: progress, really. If you're going to do all that work you may as well apply
: it to something a little more interesting.
It's actually quite interesting. :) I'm trying to create a system and a
framework that is flexible enough to be portable (with some changes)
to other systems. When I'm done, I'd like to make a port to Smalltalk,
if I have the time. Most of the work that I'm doing is going into
considering: what is the ablsolute best way of doing what I'm doing?
What makes the most sense? After that, I try to optimize or hack the
code until it runs at a reasonable speed (I'd be very happy if I could
equal the speed of, say, Zork on a C64 (that is, run both on a C64
emulator and hope they run the same). I'm not sure if this is
possible, but...
I think that time spent designing a useful and elegant system for modelling
an interactive fiction world is time well spent.
-Erik
Jonadab the Unsightly One
> I'm not convinced that it would be any better fundamentally.
You wouldn't be alone in that, either, which explains my use
of the term "ostensibly". Well, it explains it to me at any rate;
if it's opaque to everybody else maybe I wasn't clear enough.
I meant to imply that there'd be a section of people who would
*claim* it was better, and others who would disagree with them.
So Joe Average Coder wonders if he should switch, finds out
that A: there is disagreement as to the benefit and B: he'd
have to rewrite his code. Will he switch?
Depends on who we're talking about, of course, and maybe
after finishing a game (who are we kidding) and before
starting the next it'd be easier, but there's still re-learning
involved. For benefits that some claim are wonderful
and others say aren't anything to write home about.
The Inform equivalent of Worldclass.
- jonadab
Kevin Forchione
you've made all day, eh?) and someone please explain to me why the Z-machine
is such a bad VM and why it can't simply be expanded?
Kevin
Jonadab the Unsightly One wrote in message
<365b6c2e....@news.bright.net>...
Andrew Plotkin
> Assume I know nothing about virtual machines (one of the safest assumptions
> you've made all day, eh?) and someone please explain to me why the Z-machine
> is such a bad VM and why it can't simply be expanded?
It's not bad, but it's been expanded five times by Infocom and once by
Graham Nelson, and it's starting to creak at the seams. Every hack makes a
few more assumptions, and every assumption puts more constraints on
interpreter writers, authors, and compiler writers.
My position is that to make another expansion, fixing everything that
annoys people about the current system, would add *lots* of ugliness.
Enough it's better to start over. From scratch. Call it something other
than "Z-machine", in honor of the fact that there's no presumption of
backwards compatibility.
I have been working on half of this problem for, what, a year now?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Doeadeer3
In article <no4d37...@raisin.hip.berkeley.edu>, e...@uclink4.berkeley.edu
writes:
>Thing
> on perform message
> do something useful (more objects, change them, etc.)
> return a value (number or string)
> on generate message
> print natural language information
Okay, maybe I am reading what you have written wrong, but this is not the way I
would do it, not with Inform anyway.
The VerbSubs now perform the actions. For instance, Eat, removes the object
eaten and returns a message.
The edible object's before is only called if the programmer/author does not
want the standard action for Eat.
To keep it in line with the way Inform currently behaves, I would do something
similar to that little diagram I drew before (which I did in 2 minutes, so it
isn't exact, it's a "sketch"). The performance of the action is still in a Verb
Class Object -- a default action. Otherwise the programmer/author would have to
write all the actions for all the takeable/edible/wearable objects etc.
themselves.
The beauty of the Inform library now is that the programmer/author only has to
write actions for exceptions.
Also there are no built-in objects (items) except the actor (PC). All others
are added by the programmer/author.
That is, again, if I have understood you correctly.
Doeadeer3
In article <365a1c2b...@news.bright.net>, jon...@zerospam.com (Jonadab
the Unsightly One) writes:
>But Inform's grammar as it sits is *so* flexible that to
>change it to the above horridly inflexible system
>seems intollerable. My take would be to have
>the grammar lines stay the way they are, except
>that instead of mapping to FooSub you map to the
>object Foo of class Verb.
Exactly. When I said new phrases, I misstated, I meant routine calls in the
parser would have to be replaced with object calls.
>Seriously, how would a verb object handle
>things like one verb word referring to different
>verbs depending on the direct object token
>matched? How would you handle the
>scope= token, the noun= token, or the
>routine token? I just don't see it. Grammar
>is Inform's shining strong point the way it
>is now.
I have no idea, like I said, actually writting the library OO is something I
would have no idea how to do, however, I do think it COULD be done.
The advantage is: the programmer/author can use the class inheritance then
built-in the library to create their own objects. Like when you are defining a
new verb object, you just create one that uses the standard behavior of some
already exisiting verb class. Your verb object inherits.
That's the best I can say it, sometimes I am not as articulate as I would like.
But, frankly, I think that would be niffty.
Kevin Forchione
problem with rewriting code into a new format.
Seems to me that this isn't going to be a one-person operation. Sounds like
a team effort. My impression is that we've all been sitting around the
newsgroup waiting for something to happen ... leaderless and without a
driving personality.
I know how daunting these large projects can be ... I imagine that when
Inform / Tads first came out they were almost like manna from heaven. And
it's difficult to get motivated enough to create another system, when we
look at the whole chunk it's an enormous effort.
And if we don't start ... well, we'll never fail, will we?
Kevin
Andrew Plotkin wrote in message ...
Andrew Plotkin
> I agree with the stance of avoiding backwards compatibility. I don't have a
> problem with rewriting code into a new format.
I didn't say anything about *code*. (Not game code, anyway.) I was talking
about the virtual machine.
The way I see it happening, the Inform language will remain fairly
unchanged. And the differences that *do* appear will be mostly buried in
the library. 95% of Inform game code will not have to change at all.
> Seems to me that this isn't going to be a one-person operation. Sounds like
> a team effort. My impression is that we've all been sitting around the
> newsgroup waiting for something to happen ... leaderless and without a
> driving personality.
That's not my impression.
My impressions are:
(1) The hard part is the compiler, not the VM. I could design a new VM in
a day or so, and implement it in another few days. It would accomplish
little. Making Inform compile to it, that's the driving task.
(2) I don't know if someone is already working on a new Inform back-end
(for a new VM, I mean.) Graham, for example, has been awfully quiet. (I'm
not hinting coyly here; I *really* have no idea if Graham or anyone else
is working on such a thing.)
(3) We are not in dire need of a new VM. We're getting closer, yes. But
the current Inform development system is still working for almost all
works-in-progress.
(4) As you might guess, I've put a lot of thought into what I want.
Whether I'm in charge of such a project or not, it's going to take a lot
of my time. And I'm still getting Glk into its final form. So I have a
personal interest in making sure this doesn't start happening yet. :-)
Jonadab the Unsightly One
> Assume I know nothing about virtual machines (one of the safest assumptions
> you've made all day, eh?) and someone please explain to me why the Z-machine
> is such a bad VM and why it can't simply be expanded?
It's not bad.
It is *limited*. There are ways to stretch those limitations, but
you can only stretch them so far before you break things.
Eventually we're going to grow out of its capabilities, at least
for some games.
- jonadab
David Given
Andrew Plotkin <erky...@netcom.com> wrote:
>(1) The hard part is the compiler, not the VM. I could design a new VM in
>a day or so, and implement it in another few days. It would accomplish
>little. Making Inform compile to it, that's the driving task.
>
>(2) I don't know if someone is already working on a new Inform back-end
>(for a new VM, I mean.) Graham, for example, has been awfully quiet. (I'm
>not hinting coyly here; I *really* have no idea if Graham or anyone else
>is working on such a thing.)
>
>(3) We are not in dire need of a new VM. We're getting closer, yes. But
>the current Inform development system is still working for almost all
>works-in-progress.
>
>(4) As you might guess, I've put a lot of thought into what I want.
>Whether I'm in charge of such a project or not, it's going to take a lot
>of my time. And I'm still getting Glk into its final form. So I have a
>personal interest in making sure this doesn't start happening yet. :-)
At the risk of boring everyone, I already *have* a compiler and VM. It's
rather different from the Z-machine, though; I think it may be possible to
write an Inform compiler for my VM, but that would require throwing away
the current compiler (and you're right, that was the hard bit).
The current compiler will need some enhancements before it can become a
proper IF language. In particular, it needs OO extensions, which I am
currently thinking about. It should be eminently suitable, though.
As usual, you can get everything off my web page.
--
+- David Given ----------------+
| Work: d...@tao.co.uk | In capitalism, man exploits man. With
| Play: dgi...@iname.com | communism, it's exactly the opposite.
+- http://wiredsoc.ml.org/~dg -+
e...@uclink4.berkeley.edu
> Okay, maybe I am reading what you have written wrong, but this is not the way I
> would do it, not with Inform anyway.
> The VerbSubs now perform the actions. For instance, Eat, removes the object
> eaten and returns a message.
> The edible object's before is only called if the programmer/author does not
> want the standard action for Eat.
> To keep it in line with the way Inform currently behaves, I would do something
> similar to that little diagram I drew before (which I did in 2 minutes, so it
> isn't exact, it's a "sketch"). The performance of the action is still in a Verb
> Class Object -- a default action. Otherwise the programmer/author would have to
> write all the actions for all the takeable/edible/wearable objects etc.
> themselves.
> The beauty of the Inform library now is that the programmer/author only has to
> write actions for exceptions.
> Also there are no built-in objects (items) except the actor (PC). All others
> are added by the programmer/author.
> That is, again, if I have understood you correctly.
> Doe :-)
You've understood me kinda sorta. :) You are right; there should be default
behaviors for objects. That's why we have classes. Every useful object is
of class Thing, which defines certain things (standard responses/actions
for eating, moving, dropping, etc.) If you want to make something edible,
you make it of class Edible. To make it wearable, of class Werarable. And
so on and so forth.
So, the author only defines things for exceptions; we have the standard class
Thing, plus a number of typical extensions to this class (Edible, Wearable,
Container, Supporter, etc.)
Does this make sense?
--Erik
Doeadeer3
In article <stvq37...@raisin.hip.berkeley.edu>, e...@uclink4.berkeley.edu
writes:
>So, the author only defines things for exceptions; we have the standard class
>Thing, plus a number of typical extensions to this class (Edible, Wearable,
>Container, Supporter, etc.)
>
>Does this make sense?
Yes, I just hadn't viewed it that way. Hmmm, I am still not sure that that
wouldn't make it HARDER for an IF author (especially a newbie) to write a game.
In other words, they would have to assign every object (not talking OO objects,
but manipulatible items) to a class. (Because it wouldn't be done for them.)
Object coat "coat"
class wearable;
Object book "book"
class legible;
I guess that wouldn't be too bad, but it does seem to add another layer of
complexity, which might make learning an OO library harder.
I will have to think about it some more (not relevant to what you are doing, of
course, just relevant to whether I, personally like the idea).
Good luck with your project. Hope this discussion helped a little.
David Given
Doeadeer3 <doea...@aol.com> wrote:
>In other words, they would have to assign every object (not talking OO objects,
>but manipulatible items) to a class. (Because it wouldn't be done for them.)
>
>Object coat "coat"
> class wearable;
>
>Object book "book"
> class legible;
But Inform doesn't support multiple inheritence...
Object overcoat "overcoat"
with description "An overcoat made out of old newspapers.",
class wearable, legible;
--
+- David Given ----------------+
| Work: d...@tao.co.uk | Truth is stranger than fiction, because
| Play: dgi...@iname.com | fiction has to make sense.
+- http://wiredsoc.ml.org/~dg -+
Andrew Plotkin
> In article <19981129043725...@ngol06.aol.com>,
> Doeadeer3 <doea...@aol.com> wrote:
> >In other words, they would have to assign every object (not talking OO objects,
> >but manipulatible items) to a class. (Because it wouldn't be done for them.)
> >
> >Object coat "coat"
> > class wearable;
> >
> >Object book "book"
> > class legible;
> But Inform doesn't support multiple inheritence...
Yes it does. See manual.
You have to start paying attention, though. If your Wearable and Legible
classes both define a "before" property, that's ok, because "before" is an
additive property. But if both routines override the Examine action (for
example), and return true, that's a problem. Only one will get executed.
Doeadeer3
In article <912364188.21507.0...@news.demon.co.uk>, dg@ (David
Given) writes:
>But Inform doesn't support multiple inheritence...
>
>Object overcoat "overcoat"
> with description "An overcoat made out of old newspapers.",
> class wearable, legible;
>
Yes, that is a major problem. But then I would not perform actions in objects
(item objects) the way Erik is planning to. I would perform actions in Verb
classes (and verb objects).
Even after giving it more thought.
Doeadeer3
In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) writes:
>> But Inform doesn't support multiple inheritence...
>
>Yes it does. See manual.
>
>You have to start paying attention, though. If your Wearable and Legible
>classes both define a "before" property, that's ok, because "before" is an
>additive property. But if both routines override the Examine action (for
>example), and return true, that's a problem. Only one will get executed.
I think the only one thing is what he meant, but maybe not.
Erik George Hetzner
: David Given (dg@) wrote:
:> In article <19981129043725...@ngol06.aol.com>,
:> Doeadeer3 <doea...@aol.com> wrote:
:> >In other words, they would have to assign every object (not talking OO objects,
:> >but manipulatible items) to a class. (Because it wouldn't be done for them.)
:> >
:> >Object coat "coat"
:> > class wearable;
:> >
:> >Object book "book"
:> > class legible;
:> But Inform doesn't support multiple inheritence...
: Yes it does. See manual.
: You have to start paying attention, though. If your Wearable and Legible
: classes both define a "before" property, that's ok, because "before" is an
: additive property. But if both routines override the Examine action (for
: example), and return true, that's a problem. Only one will get executed.
As long as all of your code is consolidated into certain functions,
with long switch statements, it's OK.
The Class Action Library already has more additive properties than
most small nations. And it's going to get more. They're wonderful,
wonderful things.
--Erik
Erik George Hetzner
: In article <912364188.21507.0...@news.demon.co.uk>, dg@ (David
: Given) writes:
:>But Inform doesn't support multiple inheritence...
:>
:>Object overcoat "overcoat"
:> with description "An overcoat made out of old newspapers.",
:> class wearable, legible;
:>
: Yes, that is a major problem. But then I would not perform actions in objects
: (item objects) the way Erik is planning to. I would perform actions in Verb
: classes (and verb objects).
: Even after giving it more thought.
Hmm. One more try at convincing you.
The behavior for an object, according to OO design theory (I think) ought
to belong in that object. So the code for an object that is, say, picked up,
dropped, eaten, etc. belongs in the object itself. Why? Because, if its
not, you start getting lots of special cases, like with the Inform library.
You start having large if-else statements -- "if (object has containter)", and
so on. Then, if you want to make a special kind of container -- perhaps
an item that is a container, a supporter, and wearable -- you have to
start hacking the library.
But, when the behavior is in the object, and it is well-coded, one could
just say:
Object weirdItem "weird item"
class Container Supporter Wearable,
[...]
and everything will be alright. :)
On another note, I don't see what's so much worse about:
Object box "box"
class Container,
[...];
as compared with:
Object box "box"
[...]
has container;
One only has to type TWO more letters with my way. Granted, one must
make every object an instance on some class (Thing, Room, Container, etc.)
but I think the added complexity is negligible. And I think that many
things will be made much easier.
-Erik
Doeadeer3
In article <73sfqo$r5a$2...@agate.berkeley.edu>, Erik George Hetzner
<e...@ocf.berkeley.edu> writes:
Agreed that assigning it a class is not that much more trouble than giving it
an attribute. Except all item objects will have to have classes, which may trip
some people up.
Where we differ is concerning which object is in control of the process. If one
views OO (just off the top of my head, I haven't studied any OO theory or
anything) as keeping the processes relevant to an object in that object
(keeping processes in the objects that are in charge of them), it seems to me
ACTIONS fall in the provence of the verb objects, not the item objects. The
item objects are affected by the actions, but they don't perform said actions.
The verb objects do.
So that perception is where we differ.
Doeadeer3
P.S. To my last post.
Examples:
a ball doesn't bounce, a ball is bounced
a coat doesn't wear, a coat is worn
a sandwich doesn't eat, a sandwich is eaten
etc.
I think that makes it clearer what I mean. The actions are performed by the
verb objects not the item objects.
Kory Heath
> You have to start paying attention, though. If your Wearable and Legible
> classes both define a "before" property, that's ok, because "before" is an
> additive property. But if both routines override the Examine action (for
> example), and return true, that's a problem. Only one will get executed.
And even "before" can get you in trouble, if both classes have a
"before" property that traps the same verb. Ditto for "after".
If it helps any, here's the run-down of inherited-property precedence:
1. Properties given explicitly in the object definition always take
precedence over inherited properties (or, when additive, always appear
first in the list).
2. If a class name was used as the first word of the object definition
(rather than the "object" directive), that class's properties take
precedence over the properties of any other classes from which the
object inherits (or, when additive, will appear next in the list).
3. The properties of all other classes from which an object inherits
take precedence (or, when additive, pile up in the list) in the order
that they appear in the object definition.
So in the following object definition:
Wearable overcoat "overcoat",
class Flammable Legible,
with description "An overcoat made out of old newspapers.",
before [; Touch: "Feels like old newspapers."; ];
If the classes Wearable, Flammable, and Legible all define a "before"
property, then a "before" message sent to "overcoat" would result in:
overcoat::before()
Wearable::before()
Flammable::before()
Legible::before()
(But remember that if one of these "before" routines returns non-zero,
those below it don't run. This isn't a special feature of the "before"
property; it's how all additive routine-properties work. It's an
unchangeable feature of the Inform language.)
Oh, and don't forget to apply these rules recursively to classes that
inherit from other classes. :)
--
Kory Heath
khe...@best.com
Kory Heath
> But, when the behavior is in the object, and it is well-coded, one could
> just say:
>
> Object weirdItem "weird item"
> class Container Supporter Wearable,
> [...]
>
> and everything will be alright. :)
I second the notion that this would be a much better way to structure an
IF library. (Though it's not without pitfalls; resolving inheritance
conflicts would suddenly be a much bigger issue than it is with Inform
today.) Of course, it wouldn't would work at all without multiple
inheritance. An object-oriented language without multiple inheritance
would be damn near useless for IF, if you ask me.
As an aside about this brand of object-orientation: my own suspicion is
that in a couple of years we're going to look back and wonder how the
hell we ever managed to do it any other way.
--
Kory Heath
khe...@best.com
Erik George Hetzner
: P.S. To my last post.
: Examples:
: a ball doesn't bounce, a ball is bounced
: a coat doesn't wear, a coat is worn
: a sandwich doesn't eat, a sandwich is eaten
: etc.
: I think that makes it clearer what I mean. The actions are performed by the
: verb objects not the item objects.
In a way, yes. But in another, more accurate way, no. :)
(I'm sorry, it's a quote, it's fun, it's not meant to be mean. :)
Anyhow,
a ball is dropped: it bounces.
a glass is dropped: it breaks.
a coat is worn: a person is wearing a coat.
a pair of glasses is worn: a person can see.
a sandwich is eaten: it disappears.
a poison is eaten: the eater dies.
The point is, the action is the same, the consequences of the action are
different. This is why the consquences (or behavior, or before routine,
or whatever) should be in the object itself.
Or, at least, that's what I think. :)
--Erik
Doeadeer3
>I second the notion that this would be a much better way to structure an
>IF library. (Though it's not without pitfalls; resolving inheritance
>conflicts would suddenly be a much bigger issue than it is with Inform
>today.) Of course, it wouldn't would work at all without multiple
>inheritance. An object-oriented language without multiple inheritance
>would be damn near useless for IF, if you ask me.
In article <73sk1q$f6$1...@agate.berkeley.edu>, Erik George Hetzner
<e...@ocf.berkeley.edu> writes:
>In a way, yes. But in another, more accurate way, no. :)
>(I'm sorry, it's a quote, it's fun, it's not meant to be mean. :)
Well, you guys (Kevin and Erik) know more about it than I, so if you say that
is the more accurate ;-) way to do it, I will have to take your word for it, I
guess. (Yes, I am still sounding doubtful, I guess I will have to actually see
it in practice.)
Yes, without multiple inheritance, an OO library would be totally useless.
In article <3661CECA...@best.com>, Kory Heath <khe...@best.com> writes:
>As an aside about this brand of object-orientation: my own suspicion is
>that in a couple of years we're going to look back and wonder how the
>hell we ever managed to do it any other way.
Big DITTO!!! (But it seems hard to get that point across to most.)
Still hope this discussion has helped you Erik. I think your original question
was where would you put IsObjectUntouchable and things like that. Well, if NOT
in a verb metaclass :-(, then why not in an item metaclass?
Later, Doe :-)
David Glasser
> In article <stvq37...@raisin.hip.berkeley.edu>, e...@uclink4.berkeley.edu
> writes:
>
> >So, the author only defines things for exceptions; we have the standard class
> >Thing, plus a number of typical extensions to this class (Edible, Wearable,
> >Container, Supporter, etc.)
> >
> >Does this make sense?
>
> Yes, I just hadn't viewed it that way. Hmmm, I am still not sure that that
> wouldn't make it HARDER for an IF author (especially a newbie) to write a
> game.
>
> In other words, they would have to assign every object (not talking OO
> objects, but manipulatible items) to a class. (Because it wouldn't be done
> for them.)
>
> Object coat "coat"
> class wearable;
>
> Object book "book"
> class legible;
>
> I guess that wouldn't be too bad, but it does seem to add another layer of
> complexity, which might make learning an OO library harder.
>
> I will have to think about it some more (not relevant to what you are
> doing, of course, just relevant to whether I, personally like the idea).
>
> Good luck with your project. Hope this discussion helped a little.
(For one thing, don't forget the simple
Wearable coat "coat"
syntax.)
How is typing
Food -> apple "apple"
with description "Mmm...apple",
name "apple";
any harder than
Object -> apple "apple"
with description "Mmm...apple",
name "apple"
has edible;
?
You may not be used to it, yes. But it isn't *that* much of a
difference. Heck, TADS programmers have been doing it that way for
years before Inform even existed.
--
David Glasser gla...@NOSPAMuscom.com http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net 4000 (webpage fovea.retina.net:4001)
Sadie Hawkins, official band of David Glasser: http://sadie.retina.net
"We take our icons very seriously in this class."
David Glasser
> You have to start paying attention, though. If your Wearable and Legible
> classes both define a "before" property, that's ok, because "before" is an
> additive property. But if both routines override the Examine action (for
> example), and return true, that's a problem. Only one will get executed.
Befores? We don't need no steeenking befores!
Ahem. I meant to say that if we're rewriting the library, who says we
need to use something called "before", as opposed to (say) doRead,
doTake, etc.?
(Though it might be tricky to implement if Inform doesn't support
property-pointer-thingies. Does it? I don't remember.)
David Glasser
> One only has to type TWO more letters with my way. Granted, one must
> make every object an instance on some class (Thing, Room, Container, etc.)
> but I think the added complexity is negligible. And I think that many
> things will be made much easier.
Plus, there are some of us who, when starting an Inform game, instantly
start by defining Thing and Room classes. Worked for me.
Joe Mason
>But Inform doesn't support multiple inheritence...
From the DM, p54:
Inform has "multiple inheritance", which means that any object can
inherit from any number of classes. Thus, an object has no single class;
rather, it can be a member of several classes at once.
>Object overcoat "overcoat"
> with description "An overcoat made out of old newspapers.",
> class wearable, legible;
Perfectly valid.
Joe
--
Surely you're not trying to tell us that you've never, nay _never_ walked
across miles and miles of Scottish heath searching for a witch only to
find that three go by all at once? -- Den of Iniquity
Joe Mason
>
>Agreed that assigning it a class is not that much more trouble than giving it
>an attribute. Except all item objects will have to have classes, which may trip
>some people up.
People who already know OO won't be tripped up by this.
People who want use the OO library in order to learn OO techniques will find
out about this as part of the normal learning curve.
People who don't know OO and don't want to learn should not be using the OO
library.
Joe
>Where we differ is concerning which object is in control of the process. If one
>views OO (just off the top of my head, I haven't studied any OO theory or
>anything) as keeping the processes relevant to an object in that object
>(keeping processes in the objects that are in charge of them), it seems to me
>ACTIONS fall in the provence of the verb objects, not the item objects. The
>item objects are affected by the actions, but they don't perform said actions.
>The verb objects do.
>
>So that perception is where we differ.
Erik's interpretation is cleaner than yours, because we know that individual
objects are going to have to react specially to some verbs. If we keep *all*
action code in the verb objects, then we have to override the VERBS for these
special cases.
(pseudocode)
Verb to_read
! code for verb goes here
Verb to_read_2 extends to_read
action [;
! implicit switch on object
Necronomicon: Necronomicon.summon_Cthulu();
Book_of_Madness: Player.go_mad();
default: self.to_read::action();
];
If we keep *all* action code in the item objects, then we have:
Class Thing
action [;
! implicit switch on verb
to_eat: ...
to_take: ...
to_read: ...
];
Thing Necronomicon
action [;
to_read: self.summon_Cthulu();
default: self.Thing::action();
];
Thing Book_of_Madness
action [;
to_read: Player.go_mad();
default: self.to_read::action();
];
The third option is to have *some* action code in the Verbs, and *some* in the
items. This is much more confusing then either of the other two methods.
I would argue against using verb objects at all, except to define grammar, and
I think the Inform compiler's built-in handling of grammar lines is great the
way it is and shouldn't be changed. From an OO design aspect, verbs are not
objects but messages. It's possible to implement a message as an object
(by, for instance, creating an Event object with fields for the event's
parameters, and passing it to another object's method to decode), but it's not
necessary: method calls are messages, for instance. Simply passing a verb
number as a parameter should be all that's necessary for a verb.
Something's wrong with this analysis. Something is nagging at me. Stupidly,
I post anyway. I will allow the biting intellect of the ghosts of Usenet to
point out my errors.
Joe Mason
>Andrew Plotkin <erky...@netcom.com> wrote:
>
>> You have to start paying attention, though. If your Wearable and Legible
>> classes both define a "before" property, that's ok, because "before" is an
>> additive property. But if both routines override the Examine action (for
>> example), and return true, that's a problem. Only one will get executed.
>
>Befores? We don't need no steeenking befores!
>
>Ahem. I meant to say that if we're rewriting the library, who says we
>need to use something called "before", as opposed to (say) doRead,
>doTake, etc.?
>
>(Though it might be tricky to implement if Inform doesn't support
>property-pointer-thingies. Does it? I don't remember.)
Sure does. The standard GoSub uses a lot of them, for instance.
What Andrew was saying is that if you use doTake, etc., then you have to be
careful, unlike with before. Altough you could just make doTake, etc.
additive, you then have to worry about the limit on number of common
properties.
My wish-list for the Inform language: an "inherited" keyword. That way you
could start (or end) your doTake() with "inherited doTake()" and it would work
just like an additive property, but with more flexibility. Right now you'd
need "self.Wearable::doTake()", which isn't flexible at all.
Joe Mason
>Erik's interpretation is cleaner than yours, because we know that individual
>objects are going to have to react specially to some verbs. If we keep *all*
>action code in the verb objects, then we have to override the VERBS for these
>special cases.
>
>(pseudocode)
>
>Verb to_read
> ! code for verb goes here
>
>Verb to_read_2 extends to_read
> action [;
> ! implicit switch on object
> Necronomicon: Necronomicon.summon_Cthulu();
> Book_of_Madness: Player.go_mad();
> default: self.to_read::action();
> ];
<snip>
>I would argue against using verb objects at all, except to define grammar, and
>I think the Inform compiler's built-in handling of grammar lines is great the
>way it is and shouldn't be changed. From an OO design aspect, verbs are not
>objects but messages. It's possible to implement a message as an object
>(by, for instance, creating an Event object with fields for the event's
>parameters, and passing it to another object's method to decode), but it's not
>necessary: method calls are messages, for instance. Simply passing a verb
>number as a parameter should be all that's necessary for a verb.
>
>Something's wrong with this analysis. Something is nagging at me. Stupidly,
>I post anyway. I will allow the biting intellect of the ghosts of Usenet to
>point out my errors.
Of course. I was thinking in Java, as you may be able to tell from the
"extends" keyword I used. In Inform, you can't simply extend one verb object.
So in order to put the code into verb objects, the library would have to define
all verbs as *classes* (EatVerb, TakeVerb, ReadVerb, etc.) and the game would
need to define a single final object for each verb. The "standard" Eat object
would simply be of class EatVerb, with no special behaviour. For a useful
game, however, the programmer would have to make an object which overrides some
of the default verb's actions. So an OO-library would either have to provide
default verb objects with some sort of replace mechanisms, or require the
author to create an object for every verb by hand, even if it isn't going to
extended at all.
Ick.
Andrew Plotkin
> Andrew Plotkin wrote:
> > You have to start paying attention, though. If your Wearable and Legible
> > classes both define a "before" property, that's ok, because "before" is an
> > additive property. But if both routines override the Examine action (for
> > example), and return true, that's a problem. Only one will get executed.
> And even "before" can get you in trouble, if both classes have a
> "before" property that traps the same verb. Ditto for "after".
Yeah. (That's what I meant, actually. Should have said "if both 'before'
routines override the Examine action.)
> (But remember that if one of these "before" routines returns non-zero,
> those below it don't run. This isn't a special feature of the "before"
> property; it's how all additive routine-properties work. It's an
> unchangeable feature of the Inform language.)
Actually, no. You should be able to change it by Replacing either a
library routine or a veneer routine. Not sure which one, though.
Andrew Plotkin
> Andrew Plotkin <erky...@netcom.com> wrote:
> > You have to start paying attention, though. If your Wearable and Legible
> > classes both define a "before" property, that's ok, because "before" is an
> > additive property. But if both routines override the Examine action (for
> > example), and return true, that's a problem. Only one will get executed.
> Befores? We don't need no steeenking befores!
> Ahem. I meant to say that if we're rewriting the library, who says we
> need to use something called "before", as opposed to (say) doRead,
> doTake, etc.?
*I'm* not rewriting the library. :)
> (Though it might be tricky to implement if Inform doesn't support
> property-pointer-thingies. Does it? I don't remember.)
Sure; a property identifier is an integer constant, so you can go
i = doRead;
obj.i();
I think the biggest OO-library pitfalls are going to be
(1) Strange conflicts between classes that you thought were orthogonal.
Someone wants to implement a trenchcoat as a wearable container; is that
going to mess stuff up?
(2) Making classes over-rigid. I once started putting together an OO door
class. I came up with about four places where the user might want to
change behavior. And I don't remember if the result made life difficult
for NPC-automatic-navigation systems, because I didn't have any in that
particular game.
Similarly, is your container going to be annoying if I add fluids?
In the standard Inform library, a container is defined by about five
actions: Insert, Receive, Search, LetGo, and Empty. (Ok, and EmptyT and
Transfer, but nobody uses those.) Note that Receive and LetGo are "user
hooks", as it were -- not real verbs, but stubs that default to "nothing
happens" -- and they're by far the most useful. Make sure you put in
*lots* of those.
Kory Heath
> Kory Heath (khe...@best.com) wrote:
> > And even "before" can get you in trouble, if both classes have a
> > "before" property that traps the same verb. Ditto for "after".
>
> Yeah. (That's what I meant, actually. Should have said "if both 'before'
> routines override the Examine action.)
Ah, I read you. Somehow I thought you meant "if both *classes* override
the Examine action (by providing a description property)", even though
that's obviously not what you said. However, if you *had* said that,
you still would've been right, since that would be a conflict, too.
Good cover. :)
> > (But remember that if one of these "before" routines returns non-zero,
> > those below it don't run. This isn't a special feature of the "before"
> > property; it's how all additive routine-properties work. It's an
> > unchangeable feature of the Inform language.)
>
> Actually, no. You should be able to change it by Replacing either a
> library routine or a veneer routine. Not sure which one, though.
Oh yeah - I meant to go back and qualify that "unchangeable" with an "as
far as I know"; Inform always ends up surprising me like this. Since
we're on the subject, how *does* one go about analyzing and replacing
the veneer routines? Where are they documented (function names,
parameters, etc.)? Can you actually change the behavior of:
MyObject.my_additive_prop();
without recompiling the Inform compiler? Wow.
--
Kory Heath
khe...@best.com
okbl...@usa.net
doea...@aol.com (Doeadeer3) wrote:
>
> P.S. To my last post.
>
> Examples:
>
> a ball doesn't bounce, a ball is bounced
> a coat doesn't wear, a coat is worn
> a sandwich doesn't eat, a sandwich is eaten
>
> etc.
>
> I think that makes it clearer what I mean. The actions are performed by the
> verb objects not the item objects.
>
Hmmm.
Somebody drops a ball, gravity causes the ball to fall, the ball strikes a
surface in-between the source of the gravity, the various characteristics of
the ball cause it to bend to absorb the force of the blow (of the equal and
opposite reaction), and expend that energy by altering its direction (the
alteration depending on other characteristics of the ball, such as the surface
qualities and internal composition), and all of this activity wears down the
ball, the surface bounced upon, and creates noise (unless in a vacuum).
Just roughly.
More usefully, a person bounces a ball with some intention, say "to have fun",
and his success in making the ball perform how he wishes depend on his
understanding of the behavior of the ball and ground (and any relevant
climactic conditions) and his own ability to control his force, while his
ability to have fun depends on his appreciation of randomity, chasing balls,
etcetera.
-->digression One of our problems (speaking grandiosely in the larger IF
community sense) is that we wish to model physics in a world without adverbs
and often without intentions. We say "Break glass." then "with ball" and the
program tells us we've cut our hands because the program has some default for
everything but the ten-foot-pole, when we (of course) meant to *throw* the
ball.
In IF we try to guess the player's intention and his method and often get one
or the other wrong.
-->
So: the PC code should have the dropping code (with whatever intention), the
ball should have the falling code, the ground and the ball should communicate
on the impact code (i.e., the ground has to know it's a ball and not a bomb,
and the ball has to know whether the ground is regular, soft, or what-have-you
in order to bounce back accordingly), and the PC code has to have some way of
knowing whether the intention is to catch the ball on the bounce. All this
assuming no "unusual" climactic or gravitational influences on the ball.
And, if you give the ability to bounce the ball, you have to provide for all
the different possibilities, or write off those you don't wish to. ("The ball
doesn't want to be bounced here.";-))
I think the truth is you need all these things, or someone is going to end up
putting ground code in the ball or (god forbid) the PC or put the PC code in
the ball or...ick.
My recommendation?
> BOUNCE BALL
Wheee!
;-)
[ok]
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Greg Ewing
>
> it seems to me
> ACTIONS fall in the provence of the verb objects, not the item objects. The
> item objects are affected by the actions, but they don't perform said actions.
> The verb objects do.
You're interpreting the OO metaphor too dogmatically.
OO provides a set of mechanisms, such as inheritance
and method dispatch. It's up to the programmer to
decide how to use those mechanisms to best advantage.
Problem in this case: we have a bunch of actions, and
a bunch of things operated on by those actions. Each
thing can potentially respond in a unique way to each
action. We want to be able to add new kinds of thing
with new responses, with minimum disruption to the
rest of the system.
Solution using OO mechanisms: Represent each thing
by an object. Represent each action by a method call.
For example, "turn knob" results in the Turn method
of the knob object being called. To add another kind
object with new behaviour upon being turned, we
simply give it a Turn method which overrides the
default one inherited from its base class. No need
to seek out and modify a big switch statement somewhere.
TADS and Alan are both organised this way, to very
good effect.
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
Andrew Plotkin
> > > (But remember that if one of these "before" routines returns non-zero,
> > > those below it don't run. This isn't a special feature of the "before"
> > > property; it's how all additive routine-properties work. It's an
> > > unchangeable feature of the Inform language.)
> >
> > Actually, no. You should be able to change it by Replacing either a
> > library routine or a veneer routine. Not sure which one, though.
> Oh yeah - I meant to go back and qualify that "unchangeable" with an "as
> far as I know"; Inform always ends up surprising me like this. Since
> we're on the subject, how *does* one go about analyzing and replacing
> the veneer routines? Where are they documented (function names,
> parameters, etc.)? Can you actually change the behavior of:
>
> MyObject.my_additive_prop();
>
> without recompiling the Inform compiler? Wow.
I don't think they're documented. I analyze them by reading the "veneer" C
source file in the Inform source. (And I really haven't gone into them
very much.)
But yeah, all the OO operators like obj.prop() are implemented as function
calls to veneer routines, and you can go in and rewrite them.
But I don't know if you can rewrite them *totally*. There may be semantics
built into the language syntax; there may be semantics built into the
code generator. All I can say is, if you're going to dive into that, good
luck to you. :)
David Glasser
> Still hope this discussion has helped you Erik. I think your original question
> was where would you put IsObjectUntouchable and things like that. Well, if NOT
> in a verb metaclass :-(, then why not in an item metaclass?
Certainly. There'd be an object.isTouchable that all verbs that
required touching would call before doing whatever it would do. For
complicated weird thingies, it could be overridden.
Graham Nelson
<URL:mailto:erky...@netcom.com> wrote:
> But yeah, all the OO operators like obj.prop() are implemented as function
> calls to veneer routines, and you can go in and rewrite them.
>
> But I don't know if you can rewrite them *totally*. There may be semantics
> built into the language syntax; there may be semantics built into the
> code generator. All I can say is, if you're going to dive into that, good
> luck to you. :)
The behaviour in question may be found in the veneer implementation
of CA__Pr ("call property"), at line 261 in the current "veneer.c"
source file:
if (z~=0) return z;
If this line were not there, then a list of routines would continue
running right through regardless of their return values. (A string
would still halt the process because it would be interpreted as
a print_ret; you could change this one on line 262 if you really,
really wanted to.)
Note that all of this behaviour was essentially present in Inform
5; it was just resident in the library, not the veneer.
You don't need formally to Replace veneer routines; you can just
define them. (The library does this itself, to provide rather
better object-name-printing routines that the minimal veneer
implementations, which are provided only for non-adventure-game
sort of Z-machine programs.)
A surprising thing you can do with Replace is to replace the
implementation of system functions like "random" or "child",
though, since we're on the subject...
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Doeadeer3
In article <366369...@cosc.canterbury.ac.nz>, Greg Ewing
<gr...@cosc.canterbury.ac.nz> writes:
>Solution using OO mechanisms: Represent each thing
>by an object. Represent each action by a method call.
>For example, "turn knob" results in the Turn method
>of the knob object being called. To add another kind
>object with new behaviour upon being turned, we
>simply give it a Turn method which overrides the
>default one inherited from its base class. No need
>to seek out and modify a big switch statement somewhere.
Okay ALL of you have convinced little old me, that that is the way to do it
(actions performed in item classes & objects rather than in verb classes &
objects). I got it, it makes sense. Assigning all items to classes wouldn't be
that hard.
And if I understood what a veneer routine was I would also probably understand
better how Inform COULD be rewritten into an OO library by sometimes redefining
things (or maybe not, not sure I would understand the underlying mechanics of
Inform that well anyway. Guessing that a veneer routine is one that is
"built-in" and that the library can sometimes redefine how it is used.)
So now all I REALLY could wish for is that Inform OO library itself...
Doe :-) (Keeping fingers crossed.)
e...@uclink4.berkeley.edu
> The behaviour in question may be found in the veneer implementation
> of CA__Pr ("call property"), at line 261 in the current "veneer.c"
> source file:
> if (z~=0) return z;
> If this line were not there, then a list of routines would continue
> running right through regardless of their return values. (A string
> would still halt the process because it would be interpreted as
> a print_ret; you could change this one on line 262 if you really,
> really wanted to.)
I'm going to have to play around with all of this veneer stuff. I've never
used it before. On the other hand, this behavior is essential to the use
of my library. :) I might want to change other things, though.
> You don't need formally to Replace veneer routines; you can just
> define them. (The library does this itself, to provide rather
> better object-name-printing routines that the minimal veneer
> implementations, which are provided only for non-adventure-game
> sort of Z-machine programs.)
> A surprising thing you can do with Replace is to replace the
> implementation of system functions like "random" or "child",
> though, since we're on the subject...
Hmmm.
Hmmm.
I'm sure this has got to be useful in some way -- I just can't figure
which way. A change in the object hierarchy? Allowing for, as was
discussed earlier on this group, multiple parents? A refinement
of the parent-child relationship (ooh, that sounds very psychological)?
That is, some children are "inside" their parents, while some are
"on top of" them. Should a child routine return these? Well, yes.
Oh well, it's still fun.
Erik Hetzner <e...@uclink4.berkeley.edu>
TenthStone
>Andrew Plotkin <erky...@netcom.com> wrote:
>
>> You have to start paying attention, though. If your Wearable and Legible
>> classes both define a "before" property, that's ok, because "before" is an
>> additive property. But if both routines override the Examine action (for
>> example), and return true, that's a problem. Only one will get executed.
>
>Befores? We don't need no steeenking befores!
>
>Ahem. I meant to say that if we're rewriting the library, who says we
>need to use something called "before", as opposed to (say) doRead,
>doTake, etc.?
Experience. Even in TADS, there's a general object-reaction routine,
called xobjCheck, where "x" is "d" for direct or "i" for indirect.
-----------
The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
Jeff Hatch
> I think you have to add this information to the objects, but the notion
> of "class" is the wrong way to do it. Your book is legible, burnable,
> openable, opaque, rectilinear, damageable_by_water, floats, and more.
> You really don't want to try to handle that by an inheritance hierarchy
> that allows multiple inheritance. It would turn nasty. You are better
> off denoting that an object is wearable by setting a bit to 1, and
> letting the verb handler check all the bits and figure out what to do.
If someone made an Inform OO library that had all those classes, then someone could
add a "book_class" to that library. The "book_class" would multiply inherit from
the classes legible, burnable, openable, opaque, rectilinear, and
damageable_by_water. Then a user could create a book simply by having her book
object inherit from that class.
How hard would it be to handle the inheritance? If you used separate functions for
each verb like TADS does, these classes wouldn't have many common properties anyway,
so the default Inform method for finding the right property would work as far as I
can tell.
-Rúmil
Jeff Hatch
> I think human languages and the events they describe are not
> object-oriented; they are verb-oriented. There's a reason that SVO
> (subject-verb-object) languages are more common than SOV languages. You
> want to communicate information quickly, and the verb probably communicates
> more information than the object.
Maybe, but that doesn't necessarily answer the question of how they should be
implemented in IF. And it seems to me that SVOs could be more popular just because
separating the two nouns in a sentence avoids confusion.
> It's very hackish to have to write a "hit" method for every object that is
> altered when it's hit. You can't just say, "This is a breakable object, so
> it inherits the breakable-object hit method", because it may also be a
> burning object, and inherit the burning-object hit method. You usually want
> a verb handler that inspects all the properties of the objects and decides
> what to do.
The problem that you're calling attention can be a very serious problem. But
conflicts really aren't very common. In your example, why would burning objects
have a special "hit" method? When there _is_ a natural conflict, the library
probably won't take it into account very easily either.
Off the top of my head, here's a proposal: Modify the Inform compiler to issue
warnings whenever "non-conflicting" classes or objects actually inherit two
different implementations of something like the "hit" method. Whenever you make a
new class or object that multiply inherits, check to see which methods create
conflicts, and fix any necessary problems before you take "non-conflicting" out of
the definition.
That take some extra work, but the computer would find potential conflicts for you.
If you use the verb-centered approach, you have to find all possible problems by
hand. I don't know much about Inform, but this would be theoretically possible,
right? Or are methods dynamically definable?
> How does OO make your code modular if, when you
> add handcuffs, you have to rewrite every single "take" method? Your code is
> probably more modular if you put all the code for taking things in one place.
Give the handcuffs a react_before method (or whatever it's called in Inform) that
stops you from taking things while wearing them.
-Rúmil
TenthStone
>Okay ALL of you have convinced little old me, that that is the way to do it
>(actions performed in item classes & objects rather than in verb classes &
>objects). I got it, it makes sense. Assigning all items to classes wouldn't be
>that hard.
Now that we've got you, there's a minor point to make in defense of your
old idea.
It would indeed be a good idea for the libraries to check with the verb
object before proceeding with the object. For instance, the the case of
an "Eat" verb, the parser would evaluate some method on the verb object.
That routine could indicate whether the command is acceptable, and either
return a value to indicate that (or to not indicate that, as may be
better) or actually be responsible for calling the routines itself. This
is useful for actions that depend on a general special case to continue;
e.g. if one does not know how to frotz anything, the command could be
cut off here.
>And if I understood what a veneer routine was I would also probably understand
>better how Inform COULD be rewritten into an OO library by sometimes redefining
>things (or maybe not, not sure I would understand the underlying mechanics of
>Inform that well anyway. Guessing that a veneer routine is one that is
>"built-in" and that the library can sometimes redefine how it is used.)
That's how I understand it from gleaming sundry facts from Graham's post.
David Glasser
> And if I understood what a veneer routine was I would also probably
> understand better how Inform COULD be rewritten into an OO library by
> sometimes redefining things (or maybe not, not sure I would understand the
> underlying mechanics of Inform that well anyway. Guessing that a veneer
> routine is one that is "built-in" and that the library can sometimes
> redefine how it is used.)
Basically, yes. They are a set of routines in the veneer.c (well, not
.c) Inform compiler source, written in Inform and assembly. If you
don't define (Replace isn't what you want to do) a routine with the name
of one of them (to override it) they are included. With the exception
of R_Process, DefArt, InDefArt, CDefArt, PrintShortName, and
EnglishNumber, they all contain two underlines in their names. (The
listed routines are all overloaded with much better ones by the
library).
The functions "child", "children", "elder", "eldest", "indirect",
"parent", "random", "sibling", "younger", "youngest", and "metaclass"
are not veneer. They tie directly in to ZMachine opcodes. You can
override them with a Replace, but this will be much slower than the one
ZMachine opcode required for an unreplaced version.
Phil Goetz
Doeadeer3 <doea...@aol.com> wrote:
>
>In article <no4d37...@raisin.hip.berkeley.edu>, e...@uclink4.berkeley.edu
>writes:
>
>>Thing
>> on perform message
>> do something useful (more objects, change them, etc.)
>> return a value (number or string)
>> on generate message
>> print natural language information
>
>Okay, maybe I am reading what you have written wrong, but this is not the way I
>would do it, not with Inform anyway.
>
>The VerbSubs now perform the actions. For instance, Eat, removes the object
>eaten and returns a message.
>
>The edible object's before is only called if the programmer/author does not
>want the standard action for Eat.
>...
>
>The beauty of the Inform library now is that the programmer/author only has to
>write actions for exceptions.
I agree. I was going to write a rant about this, but I didn't know people
had changed the way they were doing things. I'll rant anyway,
but maybe this rant is now obsolete?
I think human languages and the events they describe are not
object-oriented; they are verb-oriented. There's a reason that SVO
(subject-verb-object) languages are more common than SOV languages. You
want to communicate information quickly, and the verb probably communicates
more information than the object.
The use of object-oriented programming practices has really damaged adventure
programming in some cases, at least when people interpret "object" in
"object-oriented programming" as "physical object". Certainly in the case
of Zork, or at least the Fortran version that I read the source code to.
It's very hackish to have to write a "hit" method for every object that is
altered when it's hit. You can't just say, "This is a breakable object, so
it inherits the breakable-object hit method", because it may also be a
burning object, and inherit the burning-object hit method. You usually want
a verb handler that inspects all the properties of the objects and decides
what to do.
Also, the object you are trying to act on doesn't know anything about the
rest of the environment; it doesn't know to ask whether your hands are
cuffed behind your back. How does OO make your code modular if, when you
add handcuffs, you have to rewrite every single "take" method? Your code is
probably more modular if you put all the code for taking things in one place.
(It's a close call, since you might have a hard time remembering all the
verbs that might need to be altered for a new object, but usually there are
fewer verbs than objects, and the objects naturally bring the verbs that act
on them to mind, but not vice-versa.)
Phil go...@zoesis.com
Phil Goetz
Doeadeer3 <doea...@aol.com> wrote:
>
>In article <stvq37...@raisin.hip.berkeley.edu>, e...@uclink4.berkeley.edu
>writes:
>
>>So, the author only defines things for exceptions; we have the standard class
>>Thing, plus a number of typical extensions to this class (Edible, Wearable,
>>Container, Supporter, etc.)
>>
>>Does this make sense?
>
>Yes, I just hadn't viewed it that way. Hmmm, I am still not sure that that
>wouldn't make it HARDER for an IF author (especially a newbie) to write a game.
>
>
>In other words, they would have to assign every object (not talking OO objects,
>but manipulatible items) to a class. (Because it wouldn't be done for them.)
>
>Object coat "coat"
> class wearable;
>
>Object book "book"
> class legible;
>
>I guess that wouldn't be too bad, but it does seem to add another layer of
>complexity, which might make learning an OO library harder.
I think you have to add this information to the objects, but the notion
of "class" is the wrong way to do it. Your book is legible, burnable,
openable, opaque, rectilinear, damageable_by_water, floats, and more.
You really don't want to try to handle that by an inheritance hierarchy
that allows multiple inheritance. It would turn nasty. You are better
off denoting that an object is wearable by setting a bit to 1, and
letting the verb handler check all the bits and figure out what to do.
That's what my last message on "VO, not OO" meant.
Phil go...@zoesis.com
Doeadeer3
In article <7453ev$m0d$1...@prometheus.acsu.buffalo.edu>, go...@cse.buffalo.edu
(Phil Goetz) writes:
>t's very hackish to have to write a "hit" method for every object that is
>altered when it's hit. You can't just say, "This is a breakable object, so
>it inherits the breakable-object hit method", because it may also be a
>burning object, and inherit the burning-object hit method. You usually want
>a verb handler that inspects all the properties of the objects and decides
>what to do.
Well, that is what I thought (hacky to write for each), but I was told I was
wrong.
Now I am really confused.
Or maybe I was right in the first place.
Doe :-) Hehehe.
e...@uclink4.berkeley.edu
> I think human languages and the events they describe are not
> object-oriented; they are verb-oriented. There's a reason that SVO
> (subject-verb-object) languages are more common than SOV languages. You
> want to communicate information quickly, and the verb probably communicates
> more information than the object.
This may be true, but seems largely irrelevant to the matter at hand.
> The use of object-oriented programming practices has really damaged adventure
> programming in some cases, at least when people interpret "object" in
> "object-oriented programming" as "physical object". Certainly in the case
> of Zork, or at least the Fortran version that I read the source code to.
> It's very hackish to have to write a "hit" method for every object that is
> altered when it's hit. You can't just say, "This is a breakable object, so
> it inherits the breakable-object hit method", because it may also be a
> burning object, and inherit the burning-object hit method. You usually want
> a verb handler that inspects all the properties of the objects and decides
> what to do.
I don't understand why this is easier. Say we have a verb handler which looks
for a breakable attribute. Then it looks for a burning attribute? What about
other possible attributes? Pretty soon you have a huge mess of a switch
statement. If the burning object and breakable behaviors interfere,
it would be much easier to simply create a BurningBreakable class.
Truthfully, I can't even see how these two would interfere at all, so I
miss your point.
> Also, the object you are trying to act on doesn't know anything about the
> rest of the environment; it doesn't know to ask whether your hands are
> cuffed behind your back. How does OO make your code modular if, when you
> add handcuffs, you have to rewrite every single "take" method? Your code is
> probably more modular if you put all the code for taking things in one place.
> (It's a close call, since you might have a hard time remembering all the
> verbs that might need to be altered for a new object, but usually there are
> fewer verbs than objects, and the objects naturally bring the verbs that act
> on them to mind, but not vice-versa.)
There are other ways to get around this. For example, the player object has
the option of performing the action (or, in this case, not performing it).
In other words, if the player is handcuffed, the player object jumps in
and says no.
A too strict interpretation of object-oriented might lead to these problems,
but keep in mind that the subject is an object too (at least, it's a game
object).
I can't imagine trying to write verb functions in which I had to provide for
every possible object in the game. It would drive me insane, and I see
no reason not to take this concept further.
--
Erik Hetzner <e...@uclink4.berkeley.edu>
Andrew Plotkin
> > The use of object-oriented programming practices has really damaged adventure
> > programming in some cases, at least when people interpret "object" in
> > "object-oriented programming" as "physical object". Certainly in the case
> > of Zork, or at least the Fortran version that I read the source code to.
> > It's very hackish to have to write a "hit" method for every object that is
> > altered when it's hit. You can't just say, "This is a breakable object, so
> > it inherits the breakable-object hit method", because it may also be a
> > burning object, and inherit the burning-object hit method. You usually want
> > a verb handler that inspects all the properties of the objects and decides
> > what to do.
> I don't understand why this is easier. Say we have a verb handler which looks
> for a breakable attribute. Then it looks for a burning attribute? What about
> other possible attributes? Pretty soon you have a huge mess of a switch
> statement. If the burning object and breakable behaviors interfere,
> it would be much easier to simply create a BurningBreakable class.
> Truthfully, I can't even see how these two would interfere at all, so I
> miss your point.
The problem is, you're both right, because you're thinking of different
cases.
Some verbs have to handle a wide range of kinds of items similarly. Some
verbs affect each item differently. In real games, most verbs do both.
("Hit X" produces a specific message for most X, but you want to override
it for the crystal vase.)
In the standard Inform library, this is handled by having a VerbSub
routine (which you can replace) and an obj.before property (which can
override particular verbs for a particular object.) Both facilities are
necessary.
You could make this concept more OO by saying that the first facility is
"the verb property for the Object class, which is inherited by all
objects" and the second is "the verb property for the particular object."
It's the same concept, of course.
Kory Heath
> The problem is, you're both right, because you're thinking of different
> cases.
I think that some form of this "verb code"/"object code" dichotomy is
going to exist, even in the most object-oriented scenario, and I think
that "verb code" is always going to send messages to objects (or at
least access properties that can be overridden), even in the *least*
object-oriented systems. However, I think there's a disagreement of
substance about how this "verb-code" and "object-code" should be
balanced, and I think the two views are distinct enough to be given
labels, and, therefore, argued about. :)
It sounds to me like Phil wants to put as much logic as possible into
the verb code; he wants the verb code to examine the object's bit flags
(attributes), take a look at who's doing the acting, and decide what
should happen. "The actor's in handcuffs; so it can't do that. Object
is flammable *and* liquid, so this exception happens." Etc. The
"object-oriented" vision is to have "verb code" that does *as little as
possible* - ideally, does nothing but pass a bunch of messages around,
and maybe exits early if return values warrant. The idea is, of course,
to put as much code in the objects themselves, via class inheritance and
selective overriding. I want to call the first perspective "non-OO" and
the second "OO", even though they're really just points along a
spectrum.
I think one of the key points about the "OO" ideal is that the core
library code (i.e. parser and verbs) should know as little as possible
about things like "wearable", "flammable", etc., and shouldn't have to
be hacked when you want to change this kind of behavior. My main beef
about "non-OO" Inform is that there are references to attributes (like
"container" and "animate") and verbs (like ##Go, ##Take) all over the
place in the core library, and changing some of the default behavior
gets really nasty.
Here's a definition, and a challenge: a library is not fully OO (in my
terms) if the parser/verb system makes even a single reference to
"container" or "supporter". Those are concepts that the designer should
be able to remove from a game *completely*, simply by not including some
.h files. If I can do that, I've got an OO library.
--
Kory Heath
khe...@best.com
Frank Filz
>
> Phil Goetz <go...@cse.buffalo.edu> wrote:
> > Also, the object you are trying to act on doesn't know anything about the
> > rest of the environment; it doesn't know to ask whether your hands are
> > cuffed behind your back. How does OO make your code modular if, when you
> > add handcuffs, you have to rewrite every single "take" method? Your code is
> > probably more modular if you put all the code for taking things in one place.
> > (It's a close call, since you might have a hard time remembering all the
> > verbs that might need to be altered for a new object, but usually there are
> > fewer verbs than objects, and the objects naturally bring the verbs that act
> > on them to mind, but not vice-versa.)
>
> There are other ways to get around this. For example, the player object has
> the option of performing the action (or, in this case, not performing it).
> In other words, if the player is handcuffed, the player object jumps in
> and says no.
Of course yet another possibility is for the handcuffs object to have a
react_before...(and this is the one I would go with, for one thing it
means you don't need to replace the player object).
--
Frank Filz
-----------------------------
Work: mailto:ff...@us.ibm.com
Home: mailto:ff...@mindspring.com
Phil Goetz
Erik George Hetzner <e...@ocf.berkeley.edu> wrote:
>Doeadeer3 <doea...@aol.com> wrote:
>: Yes, that is a major problem. But then I would not perform actions in objects
>: (item objects) the way Erik is planning to. I would perform actions in Verb
>: classes (and verb objects).
>
>: Even after giving it more thought.
>
>Hmm. One more try at convincing you.
>
>The behavior for an object, according to OO design theory (I think) ought
>to belong in that object. So the code for an object that is, say, picked up,
>dropped, eaten, etc. belongs in the object itself. Why? Because, if its
>not, you start getting lots of special cases, like with the Inform library.
>You start having large if-else statements -- "if (object has containter)", and
>so on. Then, if you want to make a special kind of container -- perhaps
>an item that is a container, a supporter, and wearable -- you have to
>start hacking the library.
Hmm. One more try at convincing you.
The /properties/ of an object ought to belong in that object.
But the /laws/ of the physical world do not belong to objects.
The only way to create a consistent physical world is to have the laws
of physics be independent of the objects added to the world.
Phil
Erik George Hetzner
: I think that some form of this "verb code"/"object code" dichotomy is
This is, in fact, one of my goals. :) Any concept should be totally
independent on others, with the exception of the basic system. Basically,
we have different parts:
(a) the basic message passing system, init and daemon calling;
(b) the essential base class Thing;
(c) parsing and scope (player object);
(d) other useful pbjects.
A is essential. B is very important. C one could be modified,
perhaps for other languages. D could be easily removed or overrided.
Your beef with non-OO system is exactly my beef. I agree completely,
though I realize that others don't agree with me (damn them all to hell!).
I'm writing an OO library because I know it will be useful for me. I
hope that it will also be useful for others.
-Erik
Mike Roberts
>The /properties/ of an object ought to belong in that object.
>But the /laws/ of the physical world do not belong to objects.
>The only way to create a consistent physical world is to have the laws
>of physics be independent of the objects added to the world.
You're right, but you're trying to solve a different problem, I think. If
you can code a complete physical model, such that everything that happens in
the game flows from your model and there are *no special cases*, then OO
coding is unnecessary. However, I don't think this is practical at the
moment for the types of games that most of us have in mind when we talk
about IF, because these games are, in fact, giant networks of special cases.
What OO's good at is creating a framework for coding special cases within a
basic model.
Empirically, OO works pretty well for coding IF and IF libraries. I think
the biggest weaknesses in adv.t are where it veers from the OO path and
makes tests for class membership and property status. Those areas are weak
not because they diverge from some abstract OO ideal, but because they
introduce dependencies; dependencies are problematic because they make it
difficult to analyze the effects of a change. When the library checks an
object to see if it belongs to a specific class or has a particular
property, that code is inflexible with respect to adding new classes and
properties.
The handcuff example seems to argue more for OO than non-OO coding. If you
put everything in the verbs, you're going to have to introduce a test into
every verb routine for handcuffs, and then another test when you add the
cone of silence to the game, and another when the player is wearing the
blindfold, and so on. With an OO approach, you'd put the relevant code in
those objects as you add them; this even has the bonus benefit of making
them modular for use in other games.
--Mike Roberts
Note: to reply by email, please remove the "-SEENOTE" suffix (including the
hyphen) from my username, and replace it with a single underscore.
Kory Heath
> Any concept should be totally
> independent on others, with the exception of the basic system.
Without backpedalling *too* furiously :), I'd add that this statement,
if taken too generally, is probably an unattainable ideal, especially at
the higher levels. Are the concepts of opening a box, opening a book,
and opening a door totally independent of each other? Could you include
or de-include them in any combination you'd like, simply by including or
not-including .h files? Does the verb "open" exist independently of all
the classes of objects to which "open" can apply? If so, how? I don't
think these kinds of problems are insurmountable, but I suspect the
solutions are always going to require a certain amount of pragmatic
bending of the pristine OO ideal.
I do believe, however, that the core of the library (i.e. the parser)
can and should be "pristine" in this sense.
--
Kory Heath
khe...@best.com
Kory Heath
> I still can't figure out how item classes (performing actions) can prioritize
> among themselves when you have multiple inheritance. If an item object belongs,
> say, to three item classes and the actions of one class
> changes/invalidates/reverses the action of another class, how is that
> prioritzed?
>
> That seems highly confusing to me, maybe making an Inform OO library not that
> much of an improvement over the standard one.
I think it's confusing because the OO library doesn't exist yet. :)
Any OO library worth the label will provide some structured way to deal
with conflict resolution (and there isn't a single "right" way, as far
as I can see, so all of our imaginings right now have a kind of vague,
mish-mash quality to them). I suspect the whole thing will seem a lot
simpler when you can just flip to the chapter on "Resolving class
conflicts", and have it all laid out.
I *never* would have understood Inform's before/after action-interrupt
system, without having the compiler, library, and documentation right
there in front of me. If I'd simply tried to *picture* what it might be
like, based on some disjointed threads on rec.arts.int-fiction, I'd have
thought it was the most cryptic, unusable system in the world. [1]
--
Kory Heath
khe...@best.com
[1] "Isn't it anyway?" Ba-dum, dum.
Kory Heath
>
> However, that's the point of returning true: to remove all
> additional consequences. If you want to allow them you
> return false.
Yeah, I can't really think of a reason to want to change this, off the
top of my head. Nice to know it can be done, though.
> Now, if you want to halt *some* of them, and not others, you
> complicate matters. Say, for example, that the ball's before
> wants to allow the inherited before rules to run but prevent
> the verbSub from doing anything. It can either set a flag that
> will cause the last inherited rule to return true (messy), or it
> can call the inherited rules explicitely and return true.
I've thought about that last possibility, but never come up with a good
way to implement it. A "before" routine could check self.#before to see
how many routines are in the before's additive list, but I can't see any
sure-fire way to know which of those routines is the one currently being
run (and, therefore, which routines haven't been run yet, and need to be
manually called).
(Actually, I suppose you could rewrite the veneer routine to respond to
a special return value from additive properties (say, -1), so that
returning this value from an additive property routine now means "keep
running the rest of the routines as usual, but if they all return false,
go ahead and return true anyway". See, I knew we'd come up with a
reason to hack that sucker. :)
--
Kory Heath
khe...@best.com
Kory Heath
>
> contradictory classes. Order of inheritance becomes
> very significant, and newbies are gonna choke.
I can't tell if you're offering this as argument that an OO rewrite
might not be such a great thing after all, but if you are, I'm not
convinced. The current Inform library is itself a pretty serious choke
hazard for newbies, in my opinion. Things like "container" and
"supporter" being mutually exclusive attributes, and "before" and
"after" working differently for rooms than for everything else, come to
mind. I wouldn't be surprised if a well-designed and well-documented OO
library for Inform turned out to be easier for newbies to learn than the
current one. At the very least, the evidence won't really be in until
we actually have such a beast and hear what newbies have to say about
it.
--
Kory Heath
khe...@best.com
Adam J. Thornton
TenthStone <mcc...@erols.com> wrote:
>Doeadeer3 thus inscribed this day of 02 Dec 1998 02:44:27 GMT:
>>Okay ALL of you have convinced little old me, that that is the way to do it
>>(actions performed in item classes & objects rather than in verb classes &
>>objects). I got it, it makes sense. Assigning all items to classes wouldn't be
>>that hard.
>Now that we've got you, there's a minor point to make in defense of your
>old idea.
>
>It would indeed be a good idea for the libraries to check with the verb
>object before proceeding with the object. For instance, the the case of
>an "Eat" verb, the parser would evaluate some method on the verb object.
>That routine could indicate whether the command is acceptable, and either
>return a value to indicate that (or to not indicate that, as may be
>better) or actually be responsible for calling the routines itself. This
>is useful for actions that depend on a general special case to continue;
>e.g. if one does not know how to frotz anything, the command could be
>cut off here.
I can't believe I'm sitting here watching you guys reinvent the TADS way of
doing things.
But it's pretty amusing.
Not that I mind. I programmed in TADS long before Inform came along, and
there are still a great many things about it I prefer to Inform.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Doeadeer3
In article <746vma$696$1...@prometheus.acsu.buffalo.edu>, go...@cse.buffalo.edu
(Phil Goetz) writes:
>The /properties/ of an object ought to belong in that object.
>But the /laws/ of the physical world do not belong to objects.
>The only way to create a consistent physical world is to have the laws
>of physics be independent of the objects added to the world.
That makes sense. I assume you are speaking of verbs being send as messages to
objects for their response? Yes, I can buy that, I guess.
I still can't figure out how item classes (performing actions) can prioritize
among themselves when you have multiple inheritance. If an item object belongs,
say, to three item classes and the actions of one class
changes/invalidates/reverses the action of another class, how is that
prioritzed?
That seems highly confusing to me, maybe making an Inform OO library not that
much of an improvement over the standard one.
Doe :-/
Jonadab the Unsightly One
> overcoat::before()
> Wearable::before()
> Flammable::before()
> Legible::before()
>
> (But remember that if one of these "before" routines returns non-zero,
> those below it don't run. This isn't a special feature of the "before"
> property; it's how all additive routine-properties work. It's an
> unchangeable feature of the Inform language.)
However, that's the point of returning true: to remove all
additional consequences. If you want to allow them you
return false.
Now, if you want to halt *some* of them, and not others, you
complicate matters. Say, for example, that the ball's before
wants to allow the inherited before rules to run but prevent
the verbSub from doing anything. It can either set a flag that
will cause the last inherited rule to return true (messy), or it
can call the inherited rules explicitely and return true.
- jonadab
Jonadab the Unsightly One
> But Inform doesn't support multiple inheritence...
>
> Object overcoat "overcoat"
> with description "An overcoat made out of old newspapers.",
> class wearable, legible;
Replace "doesn't" with "does" and remove the comma
between "wearable" and "legible".
- jonadab
Jonadab the Unsightly One
> In other words, they would have to assign every object (not talking OO objects,
> but manipulatible items) to a class. (Because it wouldn't be done for them.)
>
> Object coat "coat"
> class wearable;
>
> Object book "book"
> class legible;
>
> I guess that wouldn't be too bad, but it does seem to add another layer of
> complexity, which might make learning an OO library harder.
The problem will be when an object needs to inherit from
contradictory classes. Order of inheritance becomes
very significant, and newbies are gonna choke.
- jonadab
Doeadeer3
>> That seems highly confusing to me, maybe making an Inform OO library not
>> that much of an improvement over the standard one.
>
>I think it's confusing because the OO library doesn't exist yet. :)
>Any OO library worth the label will provide some structured way to deal
>with conflict resolution (and there isn't a single "right" way, as far
>as I can see, so all of our imaginings right now have a kind of vague,
>mish-mash quality to them). I suspect the whole thing will seem a lot
>simpler when you can just flip to the chapter on "Resolving class
>conflicts", and have it all laid out.
I was thinking out loud here for the benefit of Erik and anyone else who might
be thinking about writing an OO Inform library.
Also voicing my remaining doubts about putting all action handling in item
classes/objects.
Seems to me there could be a LOT of class conflicts (re: Jonadab's post about
returning true, false and -1 or something, how to process the "list").
Not sure that would really be an improvement.
Doe :-)
Joe Mason
>> the verbSub from doing anything. It can either set a flag that
>> will cause the last inherited rule to return true (messy), or it
>> can call the inherited rules explicitely and return true.
>
>way to implement it. A "before" routine could check self.#before to see
Someone a while ago posted a method for iterating over all of an objects
classes. It shouldn't be too hard to use that to call "all inherited rules",
or just "the first inherited rule".
Joe
--
Surely you're not trying to tell us that you've never, nay _never_ walked
across miles and miles of Scottish heath searching for a witch only to
find that three go by all at once? -- Den of Iniquity
John Francis
Doeadeer3 <doea...@aol.com> wrote:
>
>I still can't figure out how item classes (performing actions) can prioritize
>among themselves when you have multiple inheritance. If an item object belongs,
>say, to three item classes and the actions of one class
>changes/invalidates/reverses the action of another class, how is that
>prioritzed?
Short answer - it isn't.
In general the class methods are independent. If the actions of one class
change the actions of a different class then your class hierarchy is suspect.
You need a different base class, inheriting from both classes, which provides
new implementations for all the actions which interact.
Silly example: two clases of objects: Wearable and Edible.
Most of the time there is no interaction between these classes.
(other than the normal result that if you eat an item it is destroyed)
If you want to avoid eating the clothing if it is the only article of
clothing (or unless you know the wearer _really_ well :-) then you need
a new class "Edible Clothing" to handle the interactions.
Then you can explicitly deal with the priorities in the new class.
Phil Goetz
>I think one of the key points about the "OO" ideal is that the core
>library code (i.e. parser and verbs) should know as little as possible
>about things like "wearable", "flammable", etc., and shouldn't have to
>be hacked when you want to change this kind of behavior. My main beef
>about "non-OO" Inform is that there are references to attributes (like
>"container" and "animate") and verbs (like ##Go, ##Take) all over the
>place in the core library, and changing some of the default behavior
>gets really nasty.
>
>Kory Heath
>khe...@best.com
Good summary. You want Inform to be a general-purpose language in which
you can write anything, drug hallucination worlds, Tetris, whatever,
though you may have to start from scratch. I want an interactive fiction
system that has a core physics model, so that writing a game becomes more
like filling in a database. Your method is more powerful in one way,
and I respect it, and the artist in me would like to play with it, but the
technician in me wants to build a grand world simulator that non-technicians
can use to easily create large worlds. That would be more powerful in another
sense.
Chris Crawford's Erasmatron is even more extreme; he doesn't even provide
a general-purpose programming language, in order to keep the user interface
simple and easy to use.
Phil go...@zoesis.com
David Glasser
> In article <366744B8...@best.com>, Kory Heath <khe...@best.com> writes:
>
> >> That seems highly confusing to me, maybe making an Inform OO library not
> >> that much of an improvement over the standard one.
> >
> >I think it's confusing because the OO library doesn't exist yet. :)
> >Any OO library worth the label will provide some structured way to deal
> >with conflict resolution (and there isn't a single "right" way, as far
> >as I can see, so all of our imaginings right now have a kind of vague,
> >mish-mash quality to them). I suspect the whole thing will seem a lot
> >simpler when you can just flip to the chapter on "Resolving class
> >conflicts", and have it all laid out.
>
> I was thinking out loud here for the benefit of Erik and anyone else who might
> be thinking about writing an OO Inform library.
>
> Also voicing my remaining doubts about putting all action handling in item
> classes/objects.
>
> Seems to me there could be a LOT of class conflicts (re: Jonadab's post about
> returning true, false and -1 or something, how to process the "list").
>
> Not sure that would really be an improvement.
As I've said, it works for TADS. (And, if I'm not wrong, Hugo.)
It is different, sure. And it may not be right for everyone or
everygame: that's why it is a choice.
The legion of TADS users will attest that a mostly-OO solution does
work.
(In fact, an OO library couldn't cause much more conflicts than using
this library with bunches of your own classes, which many do do.)
Doeadeer3
In article <1djj7ow.1u7...@usol-209-186-16-69.uscom.com>,
gla...@DELETEuscom.com (David Glasser) writes:
>The legion of TADS users will attest that a mostly-OO solution does
>work.
>
>(In fact, an OO library couldn't cause much more conflicts than using
>this library with bunches of your own classes, which many do do.)
Okay. Inform library just needs a rewriter who knows what he/she is doing then.
Haven't really looked at Tads except briefly, didn't realize the library was
all OO, until Mike and others posted here.
David Glasser
> In article <1djj7ow.1u7...@usol-209-186-16-69.uscom.com>,
> gla...@DELETEuscom.com (David Glasser) writes:
>
> >The legion of TADS users will attest that a mostly-OO solution does
> >work.
> >
> >(In fact, an OO library couldn't cause much more conflicts than using
> >this library with bunches of your own classes, which many do do.)
>
> Okay. Inform library just needs a rewriter who knows what he/she is doing
> then.
I'm glad we agree.
> Haven't really looked at Tads except briefly, didn't realize the library was
> all OO, until Mike and others posted here.
Now you know.
TenthStone
>I can't believe I'm sitting here watching you guys reinvent the TADS way of
>doing things.
Reinvent may be a strong way of putting it. I program in TADS myself, and
the only Inform code I've ever seen has been on this newsgroup and in the
competition game.
>But it's pretty amusing.
Definitely.
-----------
The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
Kory Heath
>
> Someone a while ago posted a method for iterating over all of an objects
> classes. It shouldn't be too hard to use that to call "all inherited rules",
> or just "the first inherited rule".
Actually, that was me (among others). :) And I knew about *that*
because I'd stumbled onto it while thinking about the issue we're
discussing now.
The problem is that I want to make the call from inside one of the
inherited rules (let's say the "before" routine). If we loop over the
object's classes and call each self.class_name::before(), we're
eventually going to call the current "before" routine, and get into an
infinite loop. What I want to do is call all of the before routines
which *follow* the current routine - the ones that haven't run yet.
We could loop over all the object's classes until we hit the class that
this "before" routine belongs to (we'd have to hard code this check into
the "before" routine, in the code that does the looping over the
classes). Then we'd run all the "before" routines which follow. The
problem with this is that the same class can actually be inherited
*twice* (or more times) by a single object. If that class's before
routine wanted to manually call the rest of the before routines, it
wouldn't know where to start, because that class appears twice in the
object's class list.
(Why would a class be inherited twice? The most common reason I can
think of involves the use of "subclasses" (classes that inherit from
other classes). Imagine you've got a Glove class and a Hat class, both
of which are subclasses of the Clothing class (that is, they both
inherit from the Clothing class). If you have an object that, for some
strange reason, is both a glove and a hat (so it inherits both Glove and
Hat), that object will actually inherit Clothing twice. If you look in
the object's class list (property #2), you'll see Clothing in there
twice. If Clothing provides a "before" routine, that routine will be
redundantly called twice (though perhaps other "before" routines will be
called between the two, depending on how everything resolves). This is
usually harmless, but in this case it causes a problem.)
We could also try looping over each routine in the "before" property
list, comparing each value to the *address* of the current "before"
routine that's running, and then calling the following "before"
routines. However, a similar problem occurs: the same before routine
can exist in this list more than once.
Since by now everyone probably thinks I'm totally insane for nit-picking
this issue to death, I may as well toss in some more nitpicky Inform
trivia. Did you know that this is perfectly legal?
Class WeirdClass,
with before
[;
Eat: "This is one before routine returning.";
]
[;
Touch: "This is a whole different before routine returning.";
]
[;
Smell: "Pretty cool, huh?";
],
after
[;
Listen: "Yep.";
]
;
--
Kory Heath
khe...@best.com
Kory Heath
>
> I can't believe I'm sitting here watching you guys reinvent the TADS way of
> doing things.
Heh. I *have* been perking my ears up at all the posts that keep saying
"yeah, that's the way TADS does it". Obviously I've got to get off my
butt and read thorugh the TADS manuals. And take a look at WorldClass
while I'm at it.
However, I'd be surprised if there weren't *some* fundamental things I'd
want to do differently (or maybe had to, because of Inform's quirky
additive property stuff, or whatever), so we probably aren't reinventing
an *identical* wheel. I agree, though, that it does seem kind of silly
to talk about rewriting the Inform library without at least taking a
look at TADS.
--
Kory Heath
khe...@best.com
Doeadeer3
>Heh. I *have* been perking my ears up at all the posts that keep saying
>"yeah, that's the way TADS does it". Obviously I've got to get off my
>butt and read thorugh the TADS manuals. And take a look at WorldClass
>while I'm at it.
Yep.
>However, I'd be surprised if there weren't *some* fundamental things I'd
>want to do differently
Evidentially, at least I have been told, Tads DOES use verb objects. So Inform
would be different, if it is rewritten the way this thread has basically
suggested (actions in item objects). And I have come around to that way of
thinking.
Can't really speak about it though, because I haven't explored Tads library
either.
Jeremy A.Smith
<19981126134847...@ngol03.aol.com>...
> The beauty of the Inform library now is that the programmer/author only
has to
> write actions for exceptions.
>
> Also there are no built-in objects (items) except the actor (PC). All
others
> are added by the programmer/author.
Infocom's player-character was an object, added by the author, as early as
Zork. It is actually possible to become the Thief in Zork (by modifying a
couple of bytes in the gamefile :-)
Jeremy.
--
Replace 'X' in e-mail with 'J' if you wish to e-mail me
On my stair-e-o - Incunabulk by Athec and Music has a Bite to Eat be, Bods
of Cunaildaire
David Glasser
> Doeadeer3 <doea...@aol.com> wrote in article
> <19981126134847...@ngol03.aol.com>...
>
> > The beauty of the Inform library now is that the programmer/author only
> has to
> > write actions for exceptions.
> >
> > Also there are no built-in objects (items) except the actor (PC). All
> others
> > are added by the programmer/author.
>
> Infocom's player-character was an object, added by the author, as early as
> Zork. It is actually possible to become the Thief in Zork (by modifying a
> couple of bytes in the gamefile :-)
How how how how how?
--
David Glasser gla...@NOSPAMuscom.com http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net 4000 (webpage fovea.retina.net:4001)
Sadie Hawkins, official band of David Glasser: http://www.port4000.com/
rec.arts.int-fiction FAQ: come.to/raiffaq
Jonadab the Unsightly One
> I've thought about that last possibility, but never come up with a good
> way to implement it. A "before" routine could check self.#before to see
> how many routines are in the before's additive list, but I can't see any
> sure-fire way to know which of those routines is the one currently being
> run (and, therefore, which routines haven't been run yet, and need to be
> manually called).
Simpler than you think: you don't need to check the property at all.
If you wrote the code for the object then you *know* which classes
it inherits from; you wrote the code for those classes, and you know
which of them have relevant before rules you need to run before
returning true.
> (Actually, I suppose you could rewrite the veneer routine to respond to
> a special return value from additive properties (say, -1), so that
> returning this value from an additive property routine now means "keep
> running the rest of the routines as usual, but if they all return false,
> go ahead and return true anyway". See, I knew we'd come up with a
> reason to hack that sucker. :)
That would also work, but it would only be necessary if you
wanted to do that in multiple cases. If you only need to do
it with one object, then the other method above is cleaner.
- jonadab
Jonadab the Unsightly One
> > The problem will be when an object needs to inherit from
> > contradictory classes. Order of inheritance becomes
> > very significant, and newbies are gonna choke.
>
> I can't tell if you're offering this as argument that an OO rewrite
> might not be such a great thing after all,
No, my argument for that was in another thread ;-)
Seriously, I was merely offering this up as something
an OO library will have to deal with.
- jonadab
Joe Mason
>> (Actually, I suppose you could rewrite the veneer routine to respond to
>> a special return value from additive properties (say, -1), so that
>> returning this value from an additive property routine now means "keep
>> running the rest of the routines as usual, but if they all return false,
>> go ahead and return true anyway". See, I knew we'd come up with a
>> reason to hack that sucker. :)
>
>That would also work, but it would only be necessary if you
>wanted to do that in multiple cases. If you only need to do
>it with one object, then the other method above is cleaner.
We're talking about doing it with every routine of every object, basically.
Kory Heath
> If you wrote the code for the object then you *know* which classes
> it inherits from; you wrote the code for those classes, and you know
> which of them have relevant before rules you need to run before
> returning true.
Right. I kind of got off the track of your original post; I was
thinking about the trickier case of having a *class's* "before" routine
allow the rest of the inherited routines to run, but still interrupt the
call to the VerbSub. In that case, the class's "before" routine can't
really know what other "before" routines follow it, so it can't just
call them manually and return true.
You're right, though: when you create an object, you know all the
classes it inherits from, so you know which routines to call manually in
the highest level "before" routine.
--
Kory Heath
khe...@best.com
Kory Heath
> > I can't tell if you're offering this as argument that an OO rewrite
> > might not be such a great thing after all,
>
> No, my argument for that was in another thread ;-)
Yeah, I remember - that's why I wasn't sure. :)
--
Kory Heath
khe...@best.com
Erik George Hetzner
: I can't believe I'm sitting here watching you guys reinvent the TADS way of
: doing things.
: But it's pretty amusing.
: Not that I mind. I programmed in TADS long before Inform came along, and
: there are still a great many things about it I prefer to Inform.
Thphhhtp!
Yes, I realize that to a large extent we are reinventing the TADS
way of things.
On the other hand, we will have a more flexible parser (multiple language
support), better support for NPCs (I think). Kind of like WorldClass,
only (maybe I hope) done right. :)
On a side note: I started using Inform because I didn't want to pay for
TADS. I know, I'm cheap. I like free software. I'd gladly give money
for Inform now, but I like getting the source and being able to change
things.
Now, of course, all of that's changed and I might as well program in TADS;
but I still like Inform. I'm used to it, it has a more flexible parser.
Plus, if I used TADS, I probably wouldn't be so prepared to rewrite the
library. It would already have a lot of the features I want to add, so
I wouldn't get to add those nifty other ones that I thing would be nice.
-Erik
Erik George Hetzner
: Doeadeer3 <doea...@aol.com> wrote in article
:> Also there are no built-in objects (items) except the actor
:> (PC). All : others :> are added by the programmer/author.
: Infocom's player-character was an object, added by the author, as early as
: Zork. It is actually possible to become the Thief in Zork (by modifying a
: couple of bytes in the gamefile :-)
Oooh! Can you tell me which bytes? :) Please please please...
In any case, another silly goal of mine is to not game any built in
game objects (Things). Not ever a player. It was simplter than I thought.
I have a Player class, and that class happens to print a prompt every
turn and parse some input from the terminal. But that doesn't mean
it has to be there. Or there can't be more than one. Or it can't get input
from a file...
I can envision games, played on a hacked interpreter, with tens of players,
each connected via a network, playing in turn...it would be quite simple,
really.
Real time games, though, among more than one person would be harder. Input
would have to be flagged and interpreted depending on which player inputted
it.
Somebody else will have to write this interpreter hack, though. My C
is rather rusty and I don't have the time.
--Erik
Kory Heath
> On the other hand, we will have a more flexible parser (multiple language
> support), better support for NPCs (I think). Kind of like WorldClass,
> only (maybe I hope) done right. :)
I haven't looked at it, but as I understand it, WorldClass was very
well-designed. Apparently games that used it ran slowly on the average
system of the time, which a lot of people complained about. Also, I
seem to recall hearing that Dave kind of dropped it before he was really
finished (can anyone confirm or deny this?). I know it's been talked
about before, but is there any consensus on why WorldClass never really
caught on? Maybe it's simply that the standard TADS library is
sufficiently well-designed and OO for most purposes.
That suspicion, by the way, is the reason I don't believe an Inform OO
library would necessarily "go the way of WorldClass". Inform's standard
library is less OO to begin with, so an OO rewrite would be a more
fundamental addition to Inform than WorldClass was to standard TADS
(which was already pretty OO).
--
Kory Heath
khe...@best.com
David Glasser
WorldClass allows you to do advanced things with scope, and has a few
cool built-in classes (Parts, Attachables (don't get me started), etc)
that normal TADS doesn't (though you could port it over). It also
standardizes capitalization, etc. on the various identifiers.
Unfortunately, you have to be careful not to hamstring yourself. If you
leave out a certain field from a verb definition (it defines what you
need to be able to do to do the verb, like touch the object or see it,
and is not required for a normal TADS verb), you can use this verb on
any object in the entire game. Good thing VirtuaTech only had one room,
or else the bug that I caught at the last moment would have allowed you
to use some verb (I forget what) on any object in the game.