languages
F.E. Barrus
(interpret that as 'none whatsoever') I'd like to start by asking
people what sort of features they'd like to see in a language
designed for adventure games.
I think the basic low-level routines should allow for fully
dynamic object-oriented programming (meaning that attributes and
methods of all objects can be modified at any time, as well as
the inheritance tree. All lists of attributes and their keys should
be expandable, so that new attributes can easily be added when needed)
and also straight-forward structured programming (perhaps resembling C)
should be allowed. All variables/parameters/functions should be
dynamically typed, but also allow for range and type checking for
error control.
Well, I've got a class now, so I'll have to continue this later. But in
the meantime, please post your comments, and also ideas about a good
language syntax as well as the overall structure.
Thanks.
Fur - Roy Riggs
>I think the basic low-level routines should allow for fully
>dynamic object-oriented programming (meaning that attributes and
>methods of all objects can be modified at any time, as well as
>the inheritance tree. All lists of attributes and their keys should
>be expandable, so that new attributes can easily be added when needed)
>and also straight-forward structured programming (perhaps resembling C)
>should be allowed. All variables/parameters/functions should be
>dynamically typed, but also allow for range and type checking for
>error control.
Gee, You left out the kitchen sink! I realize this was a post to stir
up some interest, so I'll skip nitpicking your text and explain what
we have been working on. Our language is called mob, (no, it doesnt
stand for anything really.) After our last revision, is is a
super-set of SmallTalk. We've added multiple inheritance, and special
objects called Forwarders. SmallTalk had MI for awhile, but it was
extremely broken. Despite my friend Bill sending ParkPlace bug fixes for
it, they decided to drop MI until some future release, (riiiiight.)
The really big change is for our Forwarder objects. This is a
concept we came up by ourselves. Forwarders are special objects that
you attach onto another object and can then filter all incoming
messages. Naturally, the object, nor any other object in the system
need not know it has a forwarder on it. Once removed the object again
exhibits its normal behaivor. This mechanism is a direct equivalent
to magic spells, (at least in our model it is.) For example, if you
wanted to make something invisible, you would create a forwarder that
intercepts a 'canBeSeen' message, and always return false. After
attaching the forwarder to a player, nothing can see them. I have a
whole article explaining them better that was posted last year, and
I'll mail it out to anyone who is interested. Anyway, we could not
implement these cleanly in SmallTalk with making mods to the engine
itself, so thats why we are writing our own.
One of the things I would like to get a discussion going on is
MI versus attribute bags. (I can't think of a better word for this now.)
Obviously, in the real world a single object perform more than one
task. For example, a backpack is both something you can wear, and
something you can put other things inside of. We approach this
problem using multiple inheritance, by making a class called
WearableLidContainer. It's parents are Wearable, Lid, and Container.
(I guess I forgot to mention they can be opened or closed.) Now the
other approach I have heard of is to give every object some sort of a
bag and in this bag, put objects that describe the objects behavior.
(In case you are wondering, by a bag I mean an unordered collection.)
For example, if you had a sword it would be an object with a weapon
object in its bag. This approach has the advantage of easily changing
what an item is on the fly. If someone casted a light spell on the
sword, you can just plop a light object into its bag. This seems to
be a very attractive idea at first, but I am afraid it will quickly
break down in practice. In the backpack example, obviously the fact
that the item can be worn affects how it may contain things. The
wearer cannot add and remove things from it and be wearing it at the
same time. Where would you put this code in the attribute model??
Would you have a method like: (Warning, C++ psuedo code follows since
most readers probly don't know SmallTalk)
/* in the container class... */
void Container::put(self, object, player)
{
attribute a;
if ((a = findAttribute(self, "wearable")) != 0) {
if (isCurrentlyWorn(a) == TRUE) {
output("You will have to take that off first!\n");
}
} else {
/* blah blah, dont rag on this code, i know its hosed */
}
}
This seems incredibly broken to me, (read anti-OO.) There has to be
some special case code somewhere to implement the desired behavior,
but I think with this method it is going to be sprinkled throughout
all of your code. With MI, its guaranteed to all be inside of the
WearableLidContainer class. The downfall of MI is that if we have a
sword we want to provide light, we have to design a LightedWeapon
class (before hand :( ), do a become: on the sword, and then magically
decide which instVars to copy over, etc. This is rather annoying.
Fortunately, we can use forwarders in trivial cases such as this,
since being lighted and being a weapon really dont interfere with each
other.
Any other ideas?? I welcome any mail, discussion, etc..
fur - g...@mentor.cc.purdue.edu
Team Cthulhu is, and shall always be: Bill Burdick - g...@mentor.cc.purdue.edu
Roy Riggs - g...@mentor.cc.purdue.edu Mitch Adler - g...@mentor.cc.purdue.edu
F.E. Barrus
> Our language is called mob, (no, it doesnt
> stand for anything really.) After our last revision, is is a
> super-set of SmallTalk.
I realize that a description of it was posted long ago, but could you
post an updated description of the language, along with more in-depth
examples of its features?
> One of the things I would like to get a discussion going on is
> MI versus attribute bags. (I can't think of a better word for this now.)
Well, in my language I support multiple inheritance by having the
object's class be simple another attribute, which has a list of objects
to search whenever an attribute or method cannot be found in the object
itself. In fact, methods are also just ordinary attributes the way
I treat it. They are only differentiated by what they contain and
the way that they are called. Every object is just a list of attribute
keys and values, and since actual code is just defined by a typed-value
of type CODE with the value pointing to the actual code, methods are
simply defined by having an attribute with such a typed-value.
This means that you can later change what look to the program like
simple value attributes into actually being code to be evaluated.
I would post the actual high-level description of my language, except
that I keep changing it. I've got all the low-level routines
implemented, but I haven't quite made up my mind about the syntax
I want at the higher level. I'm trying to keep things somewhat
conventional, and yet that doesn't allow for a lot of things that I
want to do. For example, I'm trying to allow standard object-oriented
conventions for calling methods and such (like SmallTalk syntax), and
yet allow for the structuring of C. I've also got all the
list-processing routines of LisP, but I'm not quite sure how to make
the high-level syntax for them so that it makes some sort of logical
sense and fits in with everything else. Overall, I'm trying to keep
the language consistent as far as syntax, and also totally dynamic,
so the programmer can alter almost any aspect of it. I might simply
resort to allowing #define's (from C) for some of that, although that
always seemed to me like cheating to avoid the real problem.
Well, I have other work to get to for now. I've been buried in
coursework these past few weeks, so I haven't had any time to work on
this language. I wish there was someway I could get it to be considered
a major research project, and get funding for my time, so I could devote
myself to it, at least for a few months, if not a year.
For now, please respond with your comments. Send e-mail if you want,
although I think others would appreciate public postings if possible,
due to the lack of messages in this newsgroup.
- Frank
Yeah, I know I don't have a .sig here. I'm still too lazy to FTP one
of them from my other system, and far too lazy to write a new one.
Fur - Roy Riggs
the process of its creation we decided to change how we delt with
multiple inheritance. Some people had mailed me with questions about
forwarders, so I extracted that section (which is stable I hope!)
FORWARDERS
Forwarders are a concept we came up with a year or so ago. To really
implement magic in an adventure game, you need to have a hook into
every single function, so the spell can wedge itself anywhere into the
universe. Forwarders are our solution to this problem, you can add a
hook to ANY method (for one specific object), and do this at RUN time.
The overhead occured with the hook will only be incurred if the hook
is active, unlike in a compiled environment. Forwarders are instances
of a descendant of the Forwarder class. They work by setting an
instance variable to point to the target object, and then doing a
become with the target. Every other object in mob that used to point
to the target now points to the forwarder instead. The mechanism is
totally transparent. Now the forwarder has its doesNotUnderstand:
method defined to pass the message to the target by default.
Forwarders that want to do something interesting can check the message
first and do anything it likes with it, ignore it, change the
arguments, etc. Note: Normally forwarders are only attached to
instances. The kernal actually keeps track of two 'self's for every
object, called 'self' and 'realSelf'. When a forwarder is attached to
an object, that object's self is changed to point to the forwarder.
If you put another forwarder on top, you can form a chain. Messages
are normally passed to the self of an object. RealSelf is only used
internally by forwarders when they need to fiddle with themselves and
by a few methods defined in Object. Additionally, primitive classes
do not have mob selves, and hence may not have forwarders placed on
them.
The reason forwarders break in Smalltalk is that there is no
redirectable self. This causes forwarders to be excluded from
messages which an object sends to itself and results in inconsistent
and unexpected behavior. The tricky thing you can do in Smalltalk to
implement consistent forwarders is to define a variable to hold the
virtual self in Object and replace all occurances of self (except in a
few methods) in all methods defined for 'complex objects' (ie. not
symbols, numbers, (or other things which are copied when they are
passed as arguments to methods) with the accessing method for that
variable. So Smalltalk could conceivably do forwarders right, but
you'd have to edit virtually every method already in the system to
insure that they behave right.
----------------------------------------------------------------------
Team Cthulhu: (The mentor accounts are only until May '90)
Mitch Adler g...@mentor.cc.purdue.edu
Bill Burdick bur...@cello.ecn.purdue.edu
Roy Riggs g...@mentor.cc.purdue.edu
Jon R Ferro
I have been following this thread with some interest until the
"typesetting" of the most recent article started giving me a headache.
PLEASE, folks, think twice (or five or six times) about having anything
to do with the abomination of right-justified fixed-width text.
Fixed-width text is already hard enough on the eyes; scattering extra
spaces around only makes it worse.
--
Jon Ferro jrf...@ai.mit.edu
MIT Transportation Modelling Research Center, Documentation Committee
char*s="char*s=%c%s%c;main(){printf(s,34,s,34);}";main(){printf(s,34,s,34);}
William R Burdick
Well, in my language I support multiple inheritance by having the
object's class be simple another attribute, which has a list of objects
to search whenever an attribute or method cannot be found in the object
itself. In fact, methods are also just ordinary attributes the way
I treat it. They are only differentiated by what they contain and
the way that they are called. Every object is just a list of attribute
keys and values, and since actual code is just defined by a typed-value
of type CODE with the value pointing to the actual code, methods are
simply defined by having an attribute with such a typed-value.
This means that you can later change what look to the program like
simple value attributes into actually being code to be evaluated.
It looks to me like you are using delegation to do your inheritence.
If you are concerned at all about the efficiency of your execution you
might want to copy all the attributes of the superclasses into the
class to speed up method lookup. There will be relatively few classes,
compared to the total number of objects when a program is running, so
you won't suffer too much from the extra space and you'll reduce
execution time by an order of magnitude. Making everything generic
like that may be nice and regular, but your language may suffer for
it...
-- Bill
--
-- Bill Burdick
bur...@cello.ecn.purdue.edu
William R Burdick
FORWARDERS
Forwarders are a concept we came up with a year or so ago. To really
I should say that we didn't invent the concept of forwarders, we just
decided to use them to model spells...
F.E. Barrus
>
> It looks to me like you are using delegation to do your inheritence.
> If you are concerned at all about the efficiency of your execution you
> might want to copy all the attributes of the superclasses into the
> class to speed up method lookup. There will be relatively few classes,
> compared to the total number of objects when a program is running, so
> you won't suffer too much from the extra space and you'll reduce
> execution time by an order of magnitude. Making everything generic
> like that may be nice and regular, but your language may suffer for
> it...
Well, first of all, in my original version, I did simply copy all the
attributes and methods to the object that was to inherit them. My
reason for changing had nothing to do with saving space. On a virtual
machine that gives you 8 megs of RAM to play with, and with several
gigs of external storage, memory is not my prime concern. And, yes,
as far as execution speed, it is the best way to go, since all the
attributes are immediately attainable. The problem I had with it,
however, was that making changes to the object's class no longer
affected previously created objects. As I said before, everything
is totally dynamic and redefinable. At any time, an object's
methods or attributes can be changed, or added or deleted. Also,
an attribute can have code associated with it, to be executed to
get the attribute's value.
With the programs that I'm working on, I want a change to an object
class to globally affect all the objects of that class, not just the
new ones, but the ones already created too. The only way, that
I see to do this, is include a list of objects to be searched if
the attribute/method cannot be found locally in the object.
One other advantage of doing it this way is that any attribute
can be set back to it's "default" value (the original value inherited
from its class) simply by deleting the attribute. This then causes
all look-ups to that attribute to reference the class instead.
However, taking execution speed into consideration, or also the
possibility that an object is meant to remain static and immune to
future changes, I also have a function that will copy all the
attributes from an object's classes into the object itself.
Any other suggestions?
> -- Bill Burdick
> bur...@cello.ecn.purdue.edu
-- Frank Barrus
fra...@ritcsh.cs.rit.edu
Richard Newsome
I think traditional adventure games as such are a fossil of the soon to
be forgotten past. The new wave of adventure-oriented interactive fiction
will tend more and more toward the creation of virtual realities that
support multiple players and which will be played across networks. A
language to support this should support color 3-d wire-frame animation in
real time, computer-generated speech and sound effects with acoustically
correct stereo sound, serial port I/O, windowing, multi-tasking, shared
files, etc. In fact it might begin to look more like an operating
system than a language, with pipes channeling I/O between independently
running programs.
--
Richard Newsome
Big Electric Cat Public UNIX
..!cmcl2!hombre!dasys1!newsome