Inform - curious about experienced game coders' thoughts.
George Caswell
Hi. I'm just starting (again) to program in Inform and I'm curious about
what people who have used it for some large projects think of the language,
the library, etc.
My general impression so far is that the average Inform project is a rather
ugly mix of OO/structured/hack code. Of course, doesn't necessarily mean I'm
right. :) I'm curious about how good/bad the particular features of Inform
are once you get going, have a large project that you need to
develop/enhance/maintain/fix.
<sigh>, so sad, lost my exoframe demonstration source from 2 years back,
only have a binary...
________________________________________________
______________ _/> ____ | George Caswell: WPI CS'99. Member of SOMA team |
<___ _________// _/<_ / | LnL Projectionist-in-action! Linux+PC hobbyist.|
// <> ___ < > / _/ | "Cue!" -HP "Did you just say 'cue!'??" -CC |
// /> / / _/ / / <____ | "Yes I did..." -HP "Shit!" -CC |
// </ <<</ < _/ <______/ |_For more info see http://www.wpi.edu/~timbuktu_|
</ </
PGP 2.6.2 public key print D9 88 A0 53 DC 7E 66 F1 B7 44 D1 7E 48 95 D8 E0
Howard A. Sherman
Inform is the way to go. Easy to edit, easy to debug, easy to code and really
powerful. I just discovered a neat little trick Graham threw into Library 6/7 to
mention UNDO as a possible option when deadflag is called (eg when you die, win
the game, etc.). When I first began coding I looked at TADS and Inform as the
only two serious options and picked Inform. TADS is also quite good, so perhaps
Inform is my personal preference. Maybe I'm slanted because it seems more
Infocom-ish than TADS is.
Good luck!
Howard
Graham Nelson
In article <Pine.LNX.3.96.980420...@adamant.res.wpi.net>,
George Caswell <URL:mailto:timb...@adamant.res.wpi.net> wrote:
>
> My general impression so far is that the average Inform project is a rather
> ugly mix of OO/structured/hack code.
That's an interesting point. It's actually possible to write quite
large games without once breaking the paradigm of pure Object-ism.
Sometimes I force myself to do this, for the sake of feeling
somehow virtuous. On the other hand, most experienced Inform
writers find themselves seduced by all the quirky little hacky
things you can do if you really want to...
"Advent", for example, contains 6 entry-point routines, mostly
applying little tweaks to library behaviour, plus about 20 new
verbs, 250 objects and 7 class definitions. The code could be
more object-oriented, but (perversely) that would probably make it
less legible.
Inform does have some very hacky corners. But by and large the
style of code you write is up to you.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Magnus Olsson
In article <ant210836bc8M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>In article <Pine.LNX.3.96.980420...@adamant.res.wpi.net>,
>George Caswell <URL:mailto:timb...@adamant.res.wpi.net> wrote:
>>
>> My general impression so far is that the average Inform project is a rather
>> ugly mix of OO/structured/hack code.
>
>That's an interesting point. It's actually possible to write quite
>large games without once breaking the paradigm of pure Object-ism.
>Sometimes I force myself to do this, for the sake of feeling
>somehow virtuous. On the other hand, most experienced Inform
>writers find themselves seduced by all the quirky little hacky
>things you can do if you really want to...
This is in my experience true, but only as long as you don't
try to modify the Library. The Inform Library is not very OO at
all (due to its heritage from previous, less OO versions of the
language). But we've been through this several times before on
this newsgroup; I'd suggest you do an Alta Vista search through
the archives (search for, for example, "Inform criticism").
An interesting point: in his original article, George writes about
"large projects".
My take on this is that there are no large Inform projects. The
scaling properties of OO desing and programming are such that a
project doesn't even approach being large unless it employs dozens of
programmers and comprises hundreds of thousands of lines of codes.
Even rewriting the Inform library from scratch in a completely OO
way would only be a medium sized project in these terms. Due to the
size limitations of the Z machine, even a large z8 game would only
be a fairly small project.
OK, the above sounds incredibly snotty, as if I were telling you
amateurs that what you're doing doesn't count.
But that's not my point at all. My point is that you shouldn't judge
Inform by the standards used to judge, say, a professional C++
compiler.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
George Caswell
On Tue, 21 Apr 1998, Graham Nelson wrote:
> In article <Pine.LNX.3.96.980420...@adamant.res.wpi.net>,
> George Caswell <URL:mailto:timb...@adamant.res.wpi.net> wrote:
Shame on you... your newsreader puts my E-mail into the reply block, but
it puts in the wrong one!
> >
> > My general impression so far is that the average Inform project is a rather
> > ugly mix of OO/structured/hack code.
>
> That's an interesting point. It's actually possible to write quite
> large games without once breaking the paradigm of pure Object-ism.
> Sometimes I force myself to do this, for the sake of feeling
> somehow virtuous. On the other hand, most experienced Inform
> writers find themselves seduced by all the quirky little hacky
> things you can do if you really want to...
...
> Inform does have some very hacky corners. But by and large the
> style of code you write is up to you.
>
I guess style is the problem, and the point of my question-- I'm trying to
figure out what -is- good style for a significant Inform project, how one can
code something large in Inform without it becoming monolithic, overly
hackish, or otherwise unmanagable. I go through this with just about any new
language I learn. I can learn to do things the same way I do them in C, or I
can learn how to do them right for that language...
George Caswell
On 21 Apr 1998, Magnus Olsson wrote:
> In article <ant210836bc8M+4%@gnelson.demon.co.uk>,
> Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
> >In article <Pine.LNX.3.96.980420...@adamant.res.wpi.net>,
> >George Caswell <URL:mailto:timb...@adamant.res.wpi.net> wrote:
> >>
> >> My general impression so far is that the average Inform project is a rather
> >> ugly mix of OO/structured/hack code.
> >
...
>
> An interesting point: in his original article, George writes about
> "large projects".
>
> My take on this is that there are no large Inform projects. The
> scaling properties of OO desing and programming are such that a
> project doesn't even approach being large unless it employs dozens of
> programmers and comprises hundreds of thousands of lines of codes.
>
Right. But that's assuming you can easily split the project into modules,
in which case maintenance becomes simpler. A medium sized game will typically
have lots of modules with very ugly coupling issues because of how everything
needs to work together (and because there's no all-knowing "reality" object to
deal with the ways objects work together in standardized rules. -That- would
be a 'large project' in any system.) I think of the average game as a 'large
project' because, with the ugly coupling issues involved, and the fact that
the project almost invariably seems to result in a single monolithic block of
code and text, and that kind of coupling with so many modules always results
in something hard to manage. (an O(n!) scaling problem. Not like your
average OO program.)
> Even rewriting the Inform library from scratch in a completely OO
> way would only be a medium sized project in these terms. Due to the
> size limitations of the Z machine, even a large z8 game would only
> be a fairly small project.
>
> OK, the above sounds incredibly snotty, as if I were telling you
> amateurs that what you're doing doesn't count.
>
> But that's not my point at all. My point is that you shouldn't judge
> Inform by the standards used to judge, say, a professional C++
> compiler.
>
I think you're the only one who's done that. By 'large project' I meant a
large I-F project, or a large personal programming project. I'm trying to
figure out how to resolve what I learn in software engineering class with
Inform and other uses of spare time. Key word here is 'context'. When we're
talking about Inform, 'large project' probably doesn't -really- mean what it
means for an application developer. It means something that's a large project
in Z-Machine terms.
Part of the reason for my post is that, (to restate the issue) it seems to
me as though, by most Inform coding conventions I've seen, just about any
project will become 'large' as it approaches what the author wants it to be,
because it doesn't appear to handle modularization of games very well. I
could be wrong, before this month I hadn't coded in Inform for two years or
so.
L. Ross Raszewski
In article <ant210836bc8M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
>
> large games without once breaking the paradigm of pure Object-ism.
> Sometimes I force myself to do this, for the sake of feeling
> somehow virtuous. On the other hand, most experienced Inform
> writers find themselves seduced by all the quirky little hacky
> things you can do if you really want to...
>
>
> Inform does have some very hacky corners. But by and large the
> style of code you write is up to you.
Damned right!
I for one think that the greatrest strength of Inform is its flexibility; you
can go the pedantic oop route if you want, but you're still free to choose not
to. So many languages insist on hard-wiring abstraction, and won't allow you
to break OOP paradigms. I for one am GLAD that inform doesn't do that. (I am
also glad it's not case sensitive. It'd drive me insane.)
Leaving the "style" of the code up to the programmer is an idea that I think
has been overlooked in most other languages.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Magnus Olsson
In article <Pine.LNX.3.96.980421...@adamant.res.wpi.net>,
George Caswell <timb...@wpi.edu> wrote:
>On 21 Apr 1998, Magnus Olsson wrote:
>> An interesting point: in his original article, George writes about
>> "large projects".
>>
>> My take on this is that there are no large Inform projects. The
>> scaling properties of OO desing and programming are such that a
>> project doesn't even approach being large unless it employs dozens of
>> programmers and comprises hundreds of thousands of lines of codes.
>>
> Right. But that's assuming you can easily split the project into modules,
>in which case maintenance becomes simpler. A medium sized game will typically
>have lots of modules with very ugly coupling issues because of how everything
>needs to work together
That is an extremely important point. IF games scale differently than
most textbook examples, because you have a tendency of needing special
rules for the interaction of every single object with every other
object in the game. Also, typical IF objects tend to be singletons -
instead of having, say, a "chair" class with hundreds of (almost)
identical instances (as in an "ordinary" simulation program), you
typically get a small number of chairs that are quite different from
each other.
But this is a property of the problem domain. By its very nature, IF
is not just a simulation, but a simulation of a number of individual,
specialized entities with often rather quirky behaviour, all of which
will (in an ideal world) need to interact with every other object in
special ways (the player will sooner or later try out every
conceivable action on every object in the game, using every other
object as a tool).
So I don't really think the fundamental problem here is in the Inform
language, but in the "reality" we're trying to simulate. Don't
misunderstand me: Inform is not the ideal IF language (though none of
the current alternatives is much better), but I don't think that *any*
advance in programming languages will solve this problem, as long as
we stick to the basic paradigm of programming all the objects more or
less "manually".
But let's take another tack. What I've written above refers to the
Inform *language* - basic issues like object orientation,
modularization, and so on.
When it comes to the design of the Inform library, I'm more optimistic
in regard to the possibilities for improvement. As I've said before,
the Inform library simply isn't very OO. It has grown organically from
non-OO beginnings, and it is somewhat lacking in solid foundations
in the form of, for example, a proper OO analysis of the modelling of
actions.
It *does* have such foundations in some cases. It appears that Graham
has done a rather impressive analysis of how to model the notions of
light and visibility, for example: see the discussion in the
Designer's Manual of light sources inside closed but transparent
containers, etc. However, other concepts that are just as complex in
real life are modelled in an ad hoc and hard-to-modify way.
A very promising attempt at an IF library is WorldClass, which,
unfortunately, seems to have been abandonded halfway through. But
WorldClass has a huge potential which is largely missing from the
standard TADS library or from the Inform library.
I'm aware that these issues are more about extensibility than about
modularity. However, I think that many of the problems you seem to
have experienced could be at least be ameliorated by re-design of the
library. The basic problem: the combinatorial explosion of every
object interacting with every other object will remain, though,
until we can reach such a sophistication of modelling that supplying a
CAD drawing of each object, plus the basic laws of physics, will
suffice to specify all possible interactions :-).
>(and because there's no all-knowing "reality" object to
>deal with the ways objects work together in standardized rules. -That- would
>be a 'large project' in any system.)
If I understand you correctly, such a design would be rather the
antithesis of OO, wouldn't it? That's not to say that it may not be a
good idea to make at least *some* such rules global (or part of a
global singleton "world object). In fact, Inform's Action routines and
grammar rules fit the description in some asepcts. But it's not very
OO.
>I think of the average game as a 'large
>project' because, with the ugly coupling issues involved, and the fact that
>the project almost invariably seems to result in a single monolithic block of
>code and text, and that kind of coupling with so many modules always results
>in something hard to manage. (an O(n!) scaling problem. Not like your
>average OO program.)
Granted, counting the number of lines or the number of objects is not
a good metric in this case, when we have different scaling laws. So
lets count man-months instead (and yes, I've read "The Mythical
Man-Month"). Which is the most ambitions IF project to date? Let's say
it's "Avalon". Even if Whizzard had been working full time on the
project since he announced it, it would only be six man-years or so.
In a "large" project, we're talking about hundreds or thousands of
man-years.
>> But that's not my point at all. My point is that you shouldn't judge
>> Inform by the standards used to judge, say, a professional C++
>> compiler.
>>
> I think you're the only one who's done that.
Oh, have I, and am I?
OK, I was formulating myself a bit clumsily. I simply wanted to point
out a thing which might otherwise be overlooked. I didn't mean to
imply that you - or anybody else - was applying the wrong standards,
just that there was a risk of doing it.
>By 'large project' I meant a
>large I-F project, or a large personal programming project. I'm trying to
>figure out how to resolve what I learn in software engineering class with
>Inform and other uses of spare time. Key word here is 'context'.
Of course. No quarrel there. Would you believe me if I considered
writing something in my eralier post about the meaning of "large"
being very relative?
> Part of the reason for my post is that, (to restate the issue) it seems to
>me as though, by most Inform coding conventions I've seen
I think it's important to specify just which "coding conventions"
you're talking about here, and in what way they derive from inherent
limitations of the language, or of the Library, or whether they are
just conventions. And we should bear in mind that much of the Inform
code we see is in the nature of quick hacks by amateur programmers.
Finally, to get back to what I perceive your original question to be:
Some limitations of Inform that are obstacles to modularization have
to do with grammar and actions.
Suppose that I want to write code for handling liquids (I do, and I've
done it). I can write a set of classes that form a self-contained
module, with a nice, clearly delineated interface to the rest of the
system. However, while this "module" will have to be included at the
beginning of the program (it is not a true module, since it's not
separately compiled, but for the programmer it acts like one), any
new, liquid-related, grammar productions that I would like to add
(such as "drink", "pour") will have to be included at the end. This
makes the code much mode confusing.
Another problem, which seems to have more to do with the problem
domain than with Inform itself is that Inform verbs are global objects
that are orthogonal to everything else, in the sense that adding a new
verb can mean having to add before routines for that verb to every
object in the game. Perhaps somebody can find a better way to model
verbs, but I'm pessimistic about that.
Magnus Olsson
In article <6hir2f$cne$1...@nnrp1.dejanews.com>,
L. Ross Raszewski <rras...@hotmail.com> wrote:
>In article <ant210836bc8M+4%@gnelson.demon.co.uk>,
> Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>>
>>
>> That's an interesting point. It's actually possible to write quite
>> large games without once breaking the paradigm of pure Object-ism.
>> Sometimes I force myself to do this, for the sake of feeling
>> somehow virtuous. On the other hand, most experienced Inform
>> writers find themselves seduced by all the quirky little hacky
>> things you can do if you really want to...
>>
>[BSnip[N
>>
>> Inform does have some very hacky corners. But by and large the
>> style of code you write is up to you.
>
>Damned right!
>
>I for one think that the greatrest strength of Inform is its flexibility; you
>can go the pedantic oop route if you want, but you're still free to choose not
>to. So many languages insist on hard-wiring abstraction, and won't allow you
>to break OOP paradigms. I for one am GLAD that inform doesn't do that. (I am
>also glad it's not case sensitive. It'd drive me insane.)
Well, I'm not quite sure what you mean by "inisting on hard-wiring
abstraction". Care to elucidate?
Anyway, I think the important thing when it comes to OO and IF
programming is that the language should provide the *means* to write
nice, OO code. As I've said before, not even the largest of IF
projects (at today's state of the art) are large enough to need any
"enforcement" of programming style.
>Leaving the "style" of the code up to the programmer is an idea that I think
>has been overlooked in most other languages.
If by "style" you mean OO vs. non-OO, leaving it up to the programmer
is only a good idea if the programmer is working by himself. Having a
project where different parts are writtne using radically different
programming paradigms (Alice writes OO code, while Bob is an
old-fashioned programmer of hand-optimized numeric Fortran, and Carl
is a die-hard fan of functional programming) would be, well,
*interesting*...
George Caswell
On 21 Apr 1998, Magnus Olsson wrote:
> >(and because there's no all-knowing "reality" object to
> >deal with the ways objects work together in standardized rules. -That- would
> >be a 'large project' in any system.)
>
> If I understand you correctly, such a design would be rather the
> antithesis of OO, wouldn't it? That's not to say that it may not be a
Why? Right now everything's wired to everything else in most IF games.
If you have a set of rules that define the (general) environment of the game,
and put them in an object, that's not violating any OO principles. The object
has its own, well-defined responsibility- define and enforce the general rules
of object interaction.
The problem, the one you didn't seem to latch on to, is that it's
completely impractical. Making the rules general but functional requires way
too much information. You can't implement reality.
> >> But that's not my point at all. My point is that you shouldn't judge
> >> Inform by the standards used to judge, say, a professional C++
> >> compiler.
> >>
> > I think you're the only one who's done that.
>
> Oh, have I, and am I?
>
If you try to measure an IF project size in terms of other project sizes,
quite possibly, yes.
> > Part of the reason for my post is that, (to restate the issue) it seems to
> >me as though, by most Inform coding conventions I've seen
>
> I think it's important to specify just which "coding conventions"
> you're talking about here, and in what way they derive from inherent
> limitations of the language, or of the Library, or whether they are
> just conventions. And we should bear in mind that much of the Inform
> code we see is in the nature of quick hacks by amateur programmers.
>
I'm referring to the coding style used in every Inform program I've ever
seen. The game is made up of a monolithic block of purely disposable code.
Everything fiddles around with everything else's data, conditions are based on
unscalable criteria (like saying 'is it the red ball you had as a child' when
what you're really asking is 'is it a red ball')
I understand there are inherent problems involved, that's not my point. My
point is that I'm trying to figure out how to use inform to deal with these
problems, and deal with them well.
> Suppose that I want to write code for handling liquids (I do, and I've
> done it). I can write a set of classes that form a self-contained
> module, with a nice, clearly delineated interface to the rest of the
> system. However, while this "module" will have to be included at the
> beginning of the program (it is not a true module, since it's not
> separately compiled, but for the programmer it acts like one), any
> new, liquid-related, grammar productions that I would like to add
> (such as "drink", "pour") will have to be included at the end. This
> makes the code much mode confusing.
>
Sounds like a language (or library) problem. And there's no stone tablet
from god that says a module is separately compiled. (Well, maybe if there
were a god... :) )
> Another problem, which seems to have more to do with the problem
> domain than with Inform itself is that Inform verbs are global objects
> that are orthogonal to everything else, in the sense that adding a new
> verb can mean having to add before routines for that verb to every
> object in the game. Perhaps somebody can find a better way to model
> verbs, but I'm pessimistic about that.
>
What kinds of verbs do you find the most troublesome?
George Caswell
On Tue, 21 Apr 1998, L. Ross Raszewski wrote:
> I for one think that the greatrest strength of Inform is its flexibility; you
> can go the pedantic oop route if you want, but you're still free to choose not
Regarding OOP, I'm mostly interested in safeguarding my sanity here. So
many bugs can crop up when modules randomly fiddle with each other's data...
When each at least has to consult the other before messing around with its
data, the situation's a bit better...
> to. So many languages insist on hard-wiring abstraction, and won't allow you
> to break OOP paradigms. I for one am GLAD that inform doesn't do that. (I am
> also glad it's not case sensitive. It'd drive me insane.)
>
Then I guess you're someone I should talk to. What are the best ways
you've found for keeping your larger programs managable?
> Leaving the "style" of the code up to the programmer is an idea that I think
> has been overlooked in most other languages.
>
Not in C, or C++... in fact, I think that's actually a problem with C++...
You can do a lot with C++, with enough work you can make it be the language
you want it to be. The problems with that are 1: no one wants to write a
library to change the behavior of the language, they don't have time, and 2:
it makes it rather difficult for one creative programmer to read another
creative programmer's code. The situation is, I think, a little analogous to
a situation where the IF compiler includes woefully inadequate default
libraries. You can define anything you want, but no one has time. You can
use someone else's, but then your code may need to adapt to new versions of
theirs. You can define your own, but that takes time.
Erik Hetzner
Magnus Olsson (m...@bartlet.df.lth.se) wrote:
: But let's take another tack. What I've written above refers to the
: Inform *language* - basic issues like object orientation,
: modularization, and so on.
: When it comes to the design of the Inform library, I'm more optimistic
: in regard to the possibilities for improvement. As I've said before,
: the Inform library simply isn't very OO. It has grown organically from
: non-OO beginnings, and it is somewhat lacking in solid foundations
: in the form of, for example, a proper OO analysis of the modelling of
: actions.
I am pleased to see that this has come up here, though I would have preferred
it to come up in a couple of months rather than now, but what can you do? :)
I have been working on a more object oriented version of the Inform library,
tentatively named the Class Action Library ('cause it uses classes, and
actions, and stuff! :) I've been discussing it some on ifmud, but since
my only really concrete plans are to (a) make the library very oo, and (b)
eliminate the big distinction between the player and other objects, I
haven't been too coherent. So I'm still in the design stage, though I have
enough written that I can parse simple verbs, and cause simple things to
happen, without use of the Inform library (duh) and actually without the
use of grammar tables, which I don't like that much.
: It *does* have such foundations in some cases. It appears that Graham
: has done a rather impressive analysis of how to model the notions of
: light and visibility, for example: see the discussion in the
: Designer's Manual of light sources inside closed but transparent
: containers, etc. However, other concepts that are just as complex in
: real life are modelled in an ad hoc and hard-to-modify way.
Very true, and this is why I initally got to doing this project, because
of my difficulties easily modelling NPCs.
: A very promising attempt at an IF library is WorldClass, which,
: unfortunately, seems to have been abandonded halfway through. But
: WorldClass has a huge potential which is largely missing from the
: standard TADS library or from the Inform library.
I've checked this out, but the word on the street is that it never caught
on because it was s l o w. Way slow. Real slow like. Like pouring molasses
in winter, if you will. So I'm going to have to watch out for that, even
if most of us have whiz-bang Frotz machines, I'm going to test this
puppy on my C64 (well, okay, I'll just emulate it, but I'll make it slow).
: Finally, to get back to what I perceive your original question to be:
: Some limitations of Inform that are obstacles to modularization have
: to do with grammar and actions.
: Suppose that I want to write code for handling liquids (I do, and I've
: done it). I can write a set of classes that form a self-contained
: module, with a nice, clearly delineated interface to the rest of the
: system. However, while this "module" will have to be included at the
: beginning of the program (it is not a true module, since it's not
: separately compiled, but for the programmer it acts like one), any
: new, liquid-related, grammar productions that I would like to add
: (such as "drink", "pour") will have to be included at the end. This
: makes the code much mode confusing.
I'm not sure that I follow here. "Grammar productions"? Drink and pour
should be defined in your liquid classes, no?
: Another problem, which seems to have more to do with the problem
: domain than with Inform itself is that Inform verbs are global objects
: that are orthogonal to everything else, in the sense that adding a new
: verb can mean having to add before routines for that verb to every
: object in the game. Perhaps somebody can find a better way to model
: verbs, but I'm pessimistic about that.
Unless, of course, the verb is simple enough that it can define its own,
default routines.
In any case, as I said, I am in the design stage, and I would appreciate
any suggestions that people would have of things that they would like in
an 'ideal' IF library, or one that they would love to program in.
---- Erik Hetzner ---- I'm celebrating my love for you
er...@cafe.berkeley.edu With a pint of beer and a new tattoo.
L. Ross Raszewski
In article <Pine.LNX.3.96.980421...@adamant.res.wpi.net>,
timb...@wpi.edu wrote:
>
> Then I guess you're someone I should talk to. What are the best ways
> you've found for keeping your larger programs managable?
Multiple files. My current project includes soucre from 72 spearate files
(hey, Graham, think you could do something about that inclusion limit?). I
have one for every distinguishable area, one for each NPC , and others for
various other things. My main .inf file, for example, is 74 lines long, and
is half comments, and half Include Directives. smaller groups of files are
included from sub files, like rooms.psy, npcs.psy, and the like. The modules
stay small, and I always know where code of specific purposes go (though some
modules do get quite long nonetheless, but that can't be avoided) Also, since
most of my functionality comes from library files, I don't have to mess with
certain problems. If, say, I want to implement menu-based conversations,
rather than filling my program code (the .psy files) with lots of ugly hacks,
a menu-based conversation library (converse.h) mysteriously appears on
ftp.gmd.de, and I just include that. Modularize, compartmentalize, and
delineate. Perhaps its true most things don't fit well into narrow-minded
categories, but, having accepted this as fact, there is nothing to stop us
from from using rigid, narrow-minded categories for the same reason that
rigid, narrow-minded people use them; they make life a lot easier.
> Not in C, or C++... in fact, I think that's actually a problem with
C++...
> You can do a lot with C++, with enough work you can make it be the language
> you want it to be. The problems with that are 1: no one wants to write a
> library to change the behavior of the language, they don't have time, and 2:
> it makes it rather difficult for one creative programmer to read another
> creative programmer's code. The situation is, I think, a little analogous
to
> a situation where the IF compiler includes woefully inadequate default
> libraries. You can define anything you want, but no one has time. You can
> use someone else's, but then your code may need to adapt to new versions of
> theirs. You can define your own, but that takes time.
Well, thats the trick, isn't it... I try to make things as logical andf open
ended as I can, but the truth is, the only way you're going to produce
somethign that fully shows your own talent, and is comfortable for you to
writer is to take the risk, and develop a style that works for YOU. If
rereadability is important, then comment copiously, but don;t subserviate your
own personal style to some general sense of "right", or else you're just going
to crush your own creativity.
> ________________________________________________
> ______________ _/> ____ | George Caswell: WPI CS'99. Member of SOMA team |
> <___ _________// _/<_ / | LnL Projectionist-in-action! Linux+PC hobbyist.|
> // <> ___ < > / _/ | "Cue!" -HP "Did you just say 'cue!'??" -CC |
> // /> / / _/ / / <____ | "Yes I did..." -HP "Shit!" -CC |
> // </ <<</ < _/ <______/ |_For more info see http://www.wpi.edu/~timbuktu_|
> </ </
>
> PGP 2.6.2 public key print D9 88 A0 53 DC 7E 66 F1 B7 44 D1 7E 48 95 D8 E0
>
>
Neil K.
er...@cafe.berkeley.edu (Erik Hetzner) wrote:
> I've checked this out, but the word on the street is that it never caught
> on because it was s l o w. Way slow. Real slow like. Like pouring molasses
> in winter, if you will. So I'm going to have to watch out for that, even
> if most of us have whiz-bang Frotz machines, I'm going to test this
> puppy on my C64 (well, okay, I'll just emulate it, but I'll make it slow).
Well. When WorldClass came out, it was rightly criticized for its poor
performance on the typical machine of the day.
The irony is that the typical machine of today is more than capable of
running a WorldClass game at a decent speed. It's only slow on older
machines because WorldClass examines all possible objects when responding
to user input, not just the ones within scope. Dave Baggett designed it
this way because of the power and flexibility this lends you, arguing that
we shouldn't allow the speed of older machines to get in the way of
innovation. Of course, he was coding on big whacking-fast UNIX boxes at
MIT, so his perspective may have been a little different from someone
running TADS on a Mac Plus or IBM AT...
Anyway. It's a shame he got burnt out on IF and moved on to other things,
because it would've been nice to see WorldClass expanded and more widely
adopted. Still, the thing is on GMD in its entirety for those who want to
experiment.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Magnus Olsson
In article <6hja7n$a9c$1...@agate.berkeley.edu>,
Erik Hetzner <er...@cafe.berkeley.edu> wrote:
>Magnus Olsson (m...@bartlet.df.lth.se) wrote:
>I have been working on a more object oriented version of the Inform library,
>tentatively named the Class Action Library ('cause it uses classes, and
>actions, and stuff! :) I've been discussing it some on ifmud, but since
>my only really concrete plans are to (a) make the library very oo, and (b)
>eliminate the big distinction between the player and other objects, I
>haven't been too coherent.
Sounds exciting! But be aware that this will be quite a large undertaking
for one person. I don't know how long it took Graham to write the Inform
library, but it wasn't exactly done overnight...
My primary wish as a prospective user of this library is that you make
it extensible. Ideally, every single action the library takes should
be overridable, without the need to change anything in the library
itself. For example, Graham's Library contains many instances of code
like this:
if (noun has male) {
! do something appropriate for male NPC's
}
else if (noun has female) {
! do something else
}
else {
! do a third thing
}
where all the "!" lines really are blocks of maybe 50-100 lines of
code. This makes it very hard to do things liek adding a fourth
gender, or changing the behaviour just for female NPC's, and so on.
>: A very promising attempt at an IF library is WorldClass, which,
>: unfortunately, seems to have been abandonded halfway through. But
>: WorldClass has a huge potential which is largely missing from the
>: standard TADS library or from the Inform library.
>
>I've checked this out, but the word on the street is that it never caught
>on because it was s l o w. Way slow. Real slow like. Like pouring molasses
>in winter, if you will.
It _is_ slow, because it models the game world at a much more detailed
level than the standard TADS libraries.
As for the reasons it didn't catch on: well, I can only speak for
myself, but I decided not to use it after I noticed its half-finished
state, and an unfortunate tendency for hard-coded, hard-to-override
messages. Plus that the documentation isn't very good.
>: Suppose that I want to write code for handling liquids (I do, and I've
>: done it). I can write a set of classes that form a self-contained
>: module, with a nice, clearly delineated interface to the rest of the
>: system. However, while this "module" will have to be included at the
>: beginning of the program (it is not a true module, since it's not
>: separately compiled, but for the programmer it acts like one), any
>: new, liquid-related, grammar productions that I would like to add
>: (such as "drink", "pour") will have to be included at the end. This
>: makes the code much mode confusing.
>
>I'm not sure that I follow here. "Grammar productions"? Drink and pour
>should be defined in your liquid classes, no?
I'm referring to code like
verb 'drink' * noun -> Drink;
which must be put at the end of the program.
Magnus Olsson
>> has been overlooked in most other languages.
>>
Indeed. This is partly what I meant when I wrote that you shouldn't
judge Inform by the same standards as C++: most or all Inform projects
are small enought that you can get away with things like mixing OO and
procedural programming (or at least each programmer can decide that
for himself). I can appreciate the view that this is a strength of
Inform. But when it comes to C++, most (but far from all) people view
this as a weakness instead.
>You can do a lot with C++, with enough work you can make it be the language
>you want it to be. The problems with that are 1: no one wants to write a
>library to change the behavior of the language, they don't have time,
Well, in the case of C++ you at least have a financial incentive. A
good library that "changes the bahviour of the language" can be a
potential best-seller. A good example is the Standard Template
Library, which has not only become very popular, but has in fact been
absorbed into the ANSI C++ standard. At least for me, the STL changed
my way of programming; in effect, it became a langauge extension rather
than an "ordinary" third-party library, even before it was adopted by
the ANSI committee.
Magnus Olsson
In article <Pine.LNX.3.96.980421...@adamant.res.wpi.net>,
George Caswell <timb...@wpi.edu> wrote:
>> >(and because there's no all-knowing "reality" object to
>> >deal with the ways objects work together in standardized rules. -That- would
>> >be a 'large project' in any system.)
>>
>> If I understand you correctly, such a design would be rather the
>> antithesis of OO, wouldn't it? That's not to say that it may not be a
>
I think that's a bit of an exaggeration.
>If you have a set of rules that define the (general) environment of the game,
>and put them in an object, that's not violating any OO principles. The object
>has its own, well-defined responsibility- define and enforce the general rules
>of object interaction.
We might very well be talking about different things here, so I
shouldn't say too much, but I think this depends very much on a) to
what level you take these "general rules", and b) how the other
objects interact with the "world object".
But perhaps you could concretize your thoughts about the "world
object"? What "general rules" would it enforce? How would it do so?
>> >> But that's not my point at all. My point is that you shouldn't judge
>> >> Inform by the standards used to judge, say, a professional C++
>> >> compiler.
>> >>
>> > I think you're the only one who's done that.
>>
>> Oh, have I, and am I?
>>
> If you try to measure an IF project size in terms of other project sizes,
>quite possibly, yes.
I was merely comparing the sizes of the projects to draw the
conclusion that standard Software Engineering practice (which was,
after all, developed for projects two or three orders of magnitude
larger than your typical IF project) don't necessarily apply to
Inform.
>> I think it's important to specify just which "coding conventions"
>> you're talking about here, and in what way they derive from inherent
>> limitations of the language, or of the Library, or whether they are
>> just conventions. And we should bear in mind that much of the Inform
>> code we see is in the nature of quick hacks by amateur programmers.
>>
> I'm referring to the coding style used in every Inform program I've ever
>seen. The game is made up of a monolithic block of purely disposable code.
>Everything fiddles around with everything else's data,
This could have three causes:
1) Bad design, or absence of design. This is not surprising,
considering that most Inform programmers are not professional
programmers, and that most Inform projects are hobby projects that have
grown organically by addition of ad-hoc features and patching of
problems. OK, this sounds very pompous, but what I mean is simply that
very few Inform programmers seem to give much thought to the issues
you're raising, such as modularity, so perhaps it's not so surprising
that their programs don't exhibit much modularity etc.
(Oh, BTW, I'm not trying to pass judgement on these programmers. I
know that many of the r.a.i-f regulars started Inform programming as
complete novices, with the Designer's Manual as their only source of
information. I'm deeply impressed that you people have managed to
write so many wonderful games despite this "handicap" - for Inform is
a difficult language!)
2) Properties of the problem domain. You're complaining that every
object seems to be interacting with every other object. OK, the fact
that they haphazardly access each other's data is probably due to bad
design or sloppy programming, but the fact that the objects need to
interact may be due to the problem domain, viz. that the game tries to
simulate a world of objects that interact with each other.
3) Shortcomings of a) the Inform language or b) the Inform library.
>conditions are based on
>unscalable criteria (like saying 'is it the red ball you had as a child' when
>what you're really asking is 'is it a red ball')
Sorry, I'm not sure I follow you there. Could you please elaborate a
little? Do you think this is a problem with Inform, or with those
particular programs?
> I understand there are inherent problems involved, that's not my point. My
>point is that I'm trying to figure out how to use inform to deal with these
>problems, and deal with them well.
With all respect, this is not how I've interpreted your earlier
posts. I got the impression that you wanted to discuss the suitability
of Inform for IF programming, and whether these perceived defects in
the programs you've seen were due to shortcomings in the Inform
language or library.
I was merely trying to define the problem properly. If the structural
deficiencies of the code you're referring to are due to causes 1) or
2) in my little list above, then it not only makes no sense blaming
them on shortcomings in the Inform language, but it's downright
counterproductive doing so.
>> Suppose that I want to write code for handling liquids (I do, and I've
>> done it). I can write a set of classes that form a self-contained
>> module, with a nice, clearly delineated interface to the rest of the
>> system. However, while this "module" will have to be included at the
>> beginning of the program (it is not a true module, since it's not
>> separately compiled, but for the programmer it acts like one), any
>> new, liquid-related, grammar productions that I would like to add
>> (such as "drink", "pour") will have to be included at the end. This
>> makes the code much mode confusing.
>>
> Sounds like a language (or library) problem.
It is.
>And there's no stone tablet
>from god that says a module is separately compiled.
You'd be surprised at how many people actually do seem to think that
their particular definitions are actually written on such stone
tablets...
>> Another problem, which seems to have more to do with the problem
>> domain than with Inform itself is that Inform verbs are global objects
>> that are orthogonal to everything else, in the sense that adding a new
>> verb can mean having to add before routines for that verb to every
>> object in the game. Perhaps somebody can find a better way to model
>> verbs, but I'm pessimistic about that.
>>
> What kinds of verbs do you find the most troublesome?
It's not so much the kind of the verb, as the level of detail of the
modelling. Suppose that I add a new "drink" verb. Then it will
probably be necessary to provide detailed modelling of liquids, while
it suffices to give a default response "You can't drink that" for
everything non-liquid. In this case, I simply have the DrinkSub
routine print "You can't drink that", put a "before Drink:" case in my
liquid class, and override that case a small number of cases.
This is quite OK, I think.
However, if I implement a "pour <liquid> on <noun>" verb, then the
players will probably expect interesting things to happen when they
pour water, oil, acetone or sulphuric acid on quite a lot of different
things. It's quite a disappointment when you get things like
>pour water on cat
The cat gets wet.
not to speak of the break of mimesis caused by
>pour water on fire
The fire gets wet.
In this case, I'll either have to add "before PourOn:" cases to a lot
of objects (potentially, to every object in the game), which
non-modular, or make a big switch statement in the PourOnSub routine,
which is even more non-modular, plus a big no-no from an OO point of
view.
As I said, I don't think this is a particular shortcoming of
Inform. In fact, I can't see a much better way of doing it.
--Message-Boundary-7342--
Dan Shiovitz
In article <6hkgjn$84a$1...@bartlet.df.lth.se>,
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
[..]
>This is quite OK, I think.
>
>However, if I implement a "pour <liquid> on <noun>" verb, then the
>players will probably expect interesting things to happen when they
>pour water, oil, acetone or sulphuric acid on quite a lot of different
>things. It's quite a disappointment when you get things like
>
>>pour water on cat
>The cat gets wet.
>
>not to speak of the break of mimesis caused by
>
>>pour water on fire
>The fire gets wet.
>
>In this case, I'll either have to add "before PourOn:" cases to a lot
>of objects (potentially, to every object in the game), which
>non-modular, or make a big switch statement in the PourOnSub routine,
>which is even more non-modular, plus a big no-no from an OO point of
>view.
>
>As I said, I don't think this is a particular shortcoming of
>Inform. In fact, I can't see a much better way of doing it.
How about something like this?
water: substance
...
fire: substance
getWet() = { // extinguish the fire }
animal: substance
getWet() = { // the <animal> screeches and runs from the room! }
wood: substance
getWet() = { // the water puddles and runs off the <object> }
campFire: item
substance = fire
cat: actor
substance = animal
table: complexItem
shape = tableShape
parts = [tableTop leg1 leg2 leg3 leg4]
tableTop: item
substance = wood
etc.
I agree, this isn't a perfect solution either, but there's certainly a
lot more we could be doing for more realistic modelling.
>Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)
George Caswell
On Sat, 25 Apr 1998, Kent Tessman wrote:
> [I meant to post this a couple days ago, on the heels of George Caswell and
> Magnus Olsson talking about object-orientation, software design, and
> modularity as they apply to IF]
>
> In theory, interactive fiction--especially with the object-as-physical-entity
> approach that Hugo, Inform, TADS, etc. tend to use--should be completely
> object-orientable. In theory, one should be able to just set up for any given
> object the "world rules" that affect it and then drop it into a game where it
> will function perfectly as a discrete object.
>
(Or, like I said earlier, "you can't code reality.")
> Maybe that last point is the most important. None of us is getting paid to
> write IF, and to me the ability to fire up my editor when I have a spare
> minute and in relatively short order code up a set of sophisticated objects
> and behaviors--even if I do overstep the boundaries of OO programming, and
> even if it's going to mean some testing and bug-fixing down the road*--is such
> a benefit that any alternative is really no comparison.
>
Hrm, well I think it's possible you misunderstand my meaning a bit... I am
most interested in just finding the best way to manage interconnecting modules
in an IF project... whether or not it's an OO approach isn't important...
[Thanks for your input]
> * And again, you're never going to get rid of all the bugs no matter what you
> do. And the more abstract you get--to the level of, say, the Win32 API--the
> harder it is to fire up a debugger and track them down without pounds of API
> documentation at your side.
>
Right, but there's that O(n!) issue. It's a hell of a lot worse when the
modules have sloppy coupling, since not everything that modifies another
object's data necessarily is coded correctly to keep it in a correct state...
Debugging a module becomes a problem of debugging all the other modules that
call it.
Brock Kevin Nambo
George Caswell wrote in message ...
> (Or, like I said earlier, "you can't code reality.")
Object Reality "reality" ! the abridged version <g>
with name 'life' 'universe' 'everything',
number 42,
description "Even reality can be coded if you try hard enough!",
before
[; Take:
"Yeah, right. Where would you take it?";
Attack:
"Reality cries!";
],
has light scenery;
>>BKNambo
--
Sunflash...@msn.com
World Domination through Trivia!
[ chatquiz | onGames | MarsMission ]
Den of Iniquity
On Sun, 26 Apr 1998, Brock Kevin Nambo wrote:
>George Caswell wrote in message ...
>> (Or, like I said earlier, "you can't code reality.")
>
>Object Reality "reality" ! the abridged version <g>
> with name 'life' 'universe' 'everything',
You'd do well to stick a 'reality' in there, too. And how about
'existence'?
> number 42,
> description "Even reality can be coded if you try hard enough!",
What a disappointing reality!
> before
> [; Take:
> "Yeah, right. Where would you take it?";
You'd need to code for special circumstances like 'take life' and 'get
everything'.
> Attack:
> "Reality cries!";
Shouldn't that be
" Reality cries!";
?
> ],
> has light scenery;
T'cha! Not so easy as you thought, eh?
GET REAL
--
Den
Julian Arnold
In article <Pine.SGI.3.95L.98042...@ebor.york.ac.uk>,
Den of Iniquity <URL:mailto:dms...@york.ac.uk> wrote:
> On Sun, 26 Apr 1998, Brock Kevin Nambo wrote:
>
> >George Caswell wrote in message ...
> >> (Or, like I said earlier, "you can't code reality.")
> >
> >Object Reality "reality" ! the abridged version <g>
> > with name 'life' 'universe' 'everything',
>
> You'd do well to stick a 'reality' in there, too. And how about
> 'existence'?
>
> > number 42,
> > description "Even reality can be coded if you try hard enough!",
>
> What a disappointing reality!
>
> > before
> > [; Take:
> > "Yeah, right. Where would you take it?";
>
> You'd need to code for special circumstances like 'take life' and 'get
> everything'.
And you'd need a react_before:
react_before [;
Save, Restore, Restart:
"That's not how reality works.";
Quit:
endflag = 1; ! or whatever it is in Inform
"Probably for the best...";
Score:
"You're losing.";
],
> > Attack:
> > "Reality cries!";
>
> Shouldn't that be
> " Reality cries!";
> ?
:)
>put reality in blender
You do so. The blender whirrs into life, and soon you have a smooth mix
of Eastern culture and Western philosophy, permeated with the full rich
odour of finest Colombian coffee beans. Tastewise it's like licking a
goat though.
Or something.
> GET REAL
Get a life.
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
Brock Kevin Nambo
Den of Iniquity wrote in message ...
>On Sun, 26 Apr 1998, Brock Kevin Nambo wrote:
>
>>George Caswell wrote in message ...
>>> (Or, like I said earlier, "you can't code reality.")
>>
>>Object Reality "reality" ! the abridged version <g>
I really did mean it <G>
>> with name 'life' 'universe' 'everything',
>
>You'd do well to stick a 'reality' in there, too. And how about
>'existence'?
Hmm...
I could just go get my thesaurus and have a little field day, too, COULDNT
I?
>> number 42,
>> description "Even reality can be coded if you try hard enough!",
>
>What a disappointing reality!
Wouldn't it be disappointingier if you couldn't code it?
Hmm...
initial "Even reality can be coded if you try hard enough, and here it
is!",
description "Lots and lots of really big things, followed by lots of
really really small things, and some things in the middle that think they
own the place.",
>> before
>> [; Take:
>> "Yeah, right. Where would you take it?";
>
>You'd need to code for special circumstances like 'take life' and 'get
>everything'.
Yeah, right. Where would you take it?
>> Attack:
>> "Reality cries!";
>
>Shouldn't that be
> " Reality cries!";
>?
Uh, does it have to?
>> ],
>> has light scenery;
>
>T'cha! Not so easy as you thought, eh?
Au contraire!!! =D
>GET REAL
You don't see any "real" here.
Brock Kevin Nambo
Julian Arnold wrote in message ...
>In article <Pine.SGI.3.95L.98042...@ebor.york.ac.uk>,
>Den of Iniquity <URL:mailto:dms...@york.ac.uk> wrote:
>> You'd need to code for special circumstances like 'take life' and 'get
>> everything'.
>
> react_before [;
> Save, Restore, Restart:
> "That's not how reality works.";
> Quit:
> endflag = 1; ! or whatever it is in Inform
Uh, deadflag to win or lose, but for Quit it would probably be in an after
rule rather than a react_before. (?)
> "Probably for the best...";
> Score:
> "You're losing.";
> ],
Score:
if (player has optimism) "You're losing, but that's OK.";
>>put reality in blender
>You do so. The blender whirrs into life, and soon you have a smooth mix
>of Eastern culture and Western philosophy, permeated with the full rich
>odour of finest Colombian coffee beans. Tastewise it's like licking a
>goat though.
>
>Or something.
You have killed reality, when you were supposed to have nurtured it!
Reality cries!
>> GET REAL
>
>Get a life.
Get away from me!
Julian started a cascade!
Usenet cries!