writing i-f in C++ ?
Plugh!
obvious advantages of (multiple) inheritance, polymorphism, etc and
the obvious disadvantage that there isn't, as yet, a standard parser,
world model, etc but once the parser had been ported and a few classes
defined for room (from which we derive darkRoom), etc wouldn't we have
a wonderfully flexible and extensible system?
I suppose that Java would be just as acceptable.
I am prompted to ask this after reading "TADS vs Inform - a (vaguely)
in-depth comparison" at
http://www.cs.wisc.edu/~dbs/tads-vs-inform.html
Fell free to tell me there would be no point, as TADS & Inform are all
that we need ...
Magnus Olsson
Yes, many people have (including me) but I haven't seen any
publishjed source code so far.
>I can see the
>obvious advantages of (multiple) inheritance, polymorphism, etc and
>the obvious disadvantage that there isn't, as yet, a standard parser,
>world model, etc but once the parser had been ported and a few classes
>defined for room (from which we derive darkRoom), etc wouldn't we have
>a wonderfully flexible and extensible system?
Yes and no. In some ways, C++ would be more clumsy than languages
such as Inform and TADS which are designed to make IF programming easy.
The only area where I can think C++ would have a real advantage would
be in that you'd have access to system and third-party resources for,
say, multimedia or networking (for multiplayer IF); there's no VM in
the way that isolates you from this.
>I suppose that Java would be just as acceptable.
Or Python - there are IF libraries for Java and Python available.
>Fell free to tell me there would be no point, as TADS & Inform are all
>that we need ...
For "traditional" IF (Infocom-like), I don't think you'd gain anything
by using C++.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
L. Ross Raszewski
There would be no point; tads and inform are all we need.
But seriously, this comes up from time to time. The obvious advantage
of using a language like C++, aside from the fact that it already
supports a class model, is that it allows you to program outside the
VM sandbox. You want opengl 3d graphics with your text game? Go for
it. Etc. Also, you've got the fact that IF languages are, frankly, a
little bizarre, by the standards of conventional programming
languages.
On the other hand...
The IF community is all about portability. Write in C++, and you'll
run into portability problems the second you start to do anything
complex. More to the point, the most portable C++ program ever is only
portable in source form.
Also, C++ isn't an IF language. IF languages like Tads, Inform, Hugo,
and the rest have an insane number of niceties which are there
*because* this is an IF language. Yes, any real programming language
afficianado would consider such things cutsey hacks (except possibly
Perl gurus), but frankly, when what you're doign first and foremost is
text adventure, it's *hard* to get by without these things. Like, C++
isn't really good at the sort of circular refernce most IF systems can
implicitly create: Object X is in room Y. THis means that Object X
has a field called "parent", which is set to Y, and object Y has a
field called "child" which is set to X. This is a damned hard thing
to do in a declarative fashion in C++; you'd most likely end up with a
huge initialization routine, which would, very likely, be full of
bugs.
Also, C++ is sort of a ugly, hackish language, chock full of things
that seemed to someone or other like a good idea at the
time. polymorphism and multiple inheritance, late binding, etc, are
all handled in mysterious and bizarre ways in C++.
IF is written in a largely declarative style. Now, this is good for
C++, in that you can statically allocate most of the model-world stuff
and not worry about dynamic memory (which is probably where most
people encounter trouble most of the time). But C++ is not really
strong enough as a declarative language to handle this elegantly.
It *could* be done. Indeed, I suspect it *has* been done, back in the
old days when every comapny had their own IF design system.
The trouble is that, given the difficulties, you'd need a pretty
damned good reason to actually *do* it. Most of the areas where these
reasons exist (like, direct access to the computer hardware) are sort
of orthogonal to most IF.
* note: "We should have more systems because we should" is not a
compelling reason for such an undertaking.
* Neither is "But... dynamic memory!" -- 99.999% of all the objects in
IF are statically defined. Most people who want more dynamic memory
abilities have uses for them that are sketchy in the extreme. The
remaining cases tend to be minor (by definition, dynamically allocated
game objects must be things which you have large numbers of and which
are identical in all respects. This makes them ill suited beyond
kill-robotz, currency, pebbles on the beach, and napkins.), and can
almost always be refactored around.
* DOn't even get me started on the "crippling static memory limits"
Walter Heukels
> it. Etc. Also, you've got the fact that IF languages are, frankly, a
> little bizarre, by the standards of conventional programming
> languages.
If I might make an observation, one of the things that have always endeared
Inform to me is that it seems just quirky enough to be usable, and to be
perfectly appropriate to the subject matter... I mean, who could resist an
object-oriented programming language with operators like 'has' and 'hasnt'?
--
-- Walter Heukels <w...@xs4all.nl> -- Vegetable rights and peace! --
Magnus Olsson
>C++, in that you can statically allocate most of the model-world stuff
>and not worry about dynamic memory (which is probably where most
>people encounter trouble most of the time). But C++ is not really
>strong enough as a declarative language to handle this elegantly.
One thing that could be done is to design a new IF language that
either contains C++ as a subset, or is sufficiently similar to C++
that most code would be valid C++, and then write a translator
that takes code in the new language and outputs C++ code.
The advantages of this would be that you could write IF in the
declarative style we've all come to know and love in Inform and
TADS, and then still use all the C++ features, include third-
party C++ code, link with external libraries, and so on.
Of course, the new language wouldn't have to be similar to C++ -
you could write an Inform-to-C++ translator - but then you'd
have to hack the generated code to do the things you want to use C++
for, and C++ code machine-generated from Inform would probably be
desperately ugly.
Plugh!
http://groups.google.com/groups?hl=en&threadm=35007BC7.D59%40hatch.net&rnum=5&prev=/groups%3Fq%3Dcomparison%2Btads%2Binform%26hl%3Den%26rnum%3D5%26selm%3D35007BC7.D59%2540hatch.net
- a humungous 181 post thread "why do we need TADS & Inform?" which
probably covers most things that could be said on the subject.
I'd still like to try it in C++ though ;-)
Dan Schmidt
Just to pick a couple nits:
| Did anyone ever give any thought to writing i-f in C++? I can see the
| obvious advantages of (multiple) inheritance, polymorphism, etc and
| the obvious disadvantage that there isn't, as yet, a standard parser,
| world model, etc but once the parser had been ported and a few classes
| defined for room (from which we derive darkRoom), etc wouldn't we have
| a wonderfully flexible and extensible system?
Well, TADS and Inform have (multiple) inheritance and polymorphism too.
| I suppose that Java would be just as acceptable.
|
| I am prompted to ask this after reading "TADS vs Inform - a (vaguely)
| in-depth comparison" at
| http://www.cs.wisc.edu/~dbs/tads-vs-inform.html
You should be aware that that document is a bit out of date (one
obvious sign is the phrase, "TADS/HTML has just come out").
Kevin Forchione
news:9vs9g6$n65$4...@foobar.cs.jhu.edu...
> * Neither is "But... dynamic memory!" -- 99.999% of all the objects in
> IF are statically defined. Most people who want more dynamic memory
> abilities have uses for them that are sketchy in the extreme. The
> remaining cases tend to be minor (by definition, dynamically allocated
> game objects must be things which you have large numbers of and which
> are identical in all respects. This makes them ill suited beyond
> kill-robotz, currency, pebbles on the beach, and napkins.), and can
> almost always be refactored around.
True, dynamically-allocated game objects have pretty specialized uses. But
TADS 3 makes extensive use of dynamically allocated system objects, such as
grammar, command, and action objects. Much of what goes on inside the
parsing/command execution process involves dynamic objects, which TADS 3
handles very well.
--Kevin
L. Ross Raszewski
Oh yes; both times I've lamented the difficulty in dynamic allocation
under inform, it's been while I was doing fancy stuff deep inside the
library (I gave some serous thought to patching in some kind of
dynamic allocator for gwindows.), but This is still something of a
fringe case, as far as people just trying to write games are
concerned.
Vincent Laviano
As another data point, I've done some experiments under Inform that involve
dynamically allocating "knowledge nodes" to hang off of NPC objects when an
NPC learns something new, either through observation or conversation. One
might characterize this as a sketchy, fringe use -- for the time being -- but
I don't think it falls into the same category as napkins or pebbles. True,
these objects begin life as identical nodes, but they don't stay that way for
long.
There are some problems with this approach, one being that a limit on total
available memory translates to a cosmic Conservation of Knowledge rule across
all NPCs. One runs into cases where NPC #1 runs around learning a bunch of
trivial things and exhausting all of the memory in the process, and then
NPC #2 is unable to learn anything more because malloc fails. I suppose that
under a sophisticated NPC system with some planning capability, the second
NPC, understanding the laws of the universe, should generate a plan to go
whack the first NPC on the head a few times with a large object in order to
free up some memory. More realistically, a per-NPC memory consumption limit
would solve this particular problem, but would allow scenarios where
allocation requests are being rejected even though there will be no future
demand for that memory by another NPC.
The problem isn't specific to IF. The tradeoffs among various allocation
schemes is a long standing issue covered in most operating systems classes.
What *is* specific to IF is the need to generate some plausible explanation
within the game world for the inability to allocate a resource. With trivial
objects such as napkins from a dispenser or pebbles from the beach, it's easy
enough for the game to tell the player "You already have enough napkins to
clean even the messiest spill." However, it's not so easy to decide how an
NPC should respond to an allocation failure.
What if a failed allocation was for a node that was to contain critical
information that the PC is supposed to learn by asking the NPC? Maybe such
pieces of info should be statically allocated and controlled with a flag, or
maybe a priority system should be introduced and, in the event of resource
constraints, a higher priority item should be allowed to displace a lower
priority item in an NPC's knowledge base. ("Well, I forgot all about the east
wall, but did you know that the butler did it?")
In my view, there's lots of room for improvement on the NPC front, and one
promising approach is a deeper simulation of NPC knowledge. I'm sure there's
a point of diminishing returns, but even modest enhancements here could go a
long way. As we pursue this approach, dynamic allocation may become much more
significant.
Vince Laviano
Lewis Raszewski
>
> The problem isn't specific to IF. The tradeoffs among various allocation
> schemes is a long standing issue covered in most operating systems classes.
> What *is* specific to IF is the need to generate some plausible explanation
> within the game world for the inability to allocate a resource. With trivial
> objects such as napkins from a dispenser or pebbles from the beach, it's easy
> enough for the game to tell the player "You already have enough napkins to
> clean even the messiest spill." However, it's not so easy to decide how an
> NPC should respond to an allocation failure.
>
>
It should be noted, though, that all napkin holders I have ever
encountered out in the big scary real world have held only a finite
number of napkins, and that these napkins had been statically allocated
to it before I started pulling them out.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"And it's a bittersweet symphony, this life" -- The Verve, Bittersweet
Symphony
joh
libraries. While I have immense respect for the people working on
IF-specific languages, I see a lot of advantages to a well-designed
Java system. Including new media types would be much easier, for
instance. It would have decent cross-platform support. (Java: Write
once, wrong everywhere.) Internationalization would be easy, too.
But the main thing is that it would give more-or-less average users
the ability to tinker directly with the parser and other things that
seem hard to get at in Inform.
My plan was to try for a modular system, where the display, parser,
and world model were, as much as practical, separated. I've got a
model in my head that would allow you to simply plug in, say, an
experimental parser, or a Speech Object + Text-to-speech interface.
God knows when I'll get to it, though.
j o h !
Vincent Laviano
: Vincent Laviano wrote:
: >
: > The problem isn't specific to IF. The tradeoffs among various allocation
: > schemes is a long standing issue covered in most operating systems
: > classes. What *is* specific to IF is the need to generate some plausible
: > explanation within the game world for the inability to allocate a
: > resource. With trivial objects such as napkins from a dispenser or
: > pebbles from the beach, it's easy enough for the game to tell the player
: > "You already have enough napkins to clean even the messiest spill."
: > However, it's not so easy to decide how an NPC should respond to an
: > allocation failure.
: >
: It should be noted, though, that all napkin holders I have ever
: encountered out in the big scary real world have held only a finite
: number of napkins, and that these napkins had been statically allocated
: to it before I started pulling them out.
Sure, that's true.
My comment applies to those cases where the finite number of trivial objects
being simulated is substantially larger than the number of game objects
available to simulate them and in which we could therefore have an allocation
failure. I concede that napkins aren't the best example of such a case,
unless we're talking about a magical Dispenser of Nearly Neverending Napkins.
Also, this is more of an issue for objects that are programmatically varied
after instantiation based on random number generation or dynamic user input.
With identical objects, we can avoid an allocation failure entirely by using
a single Inform object to represent the entire collection. However, we'd
still have to use some sort of blow-off, like the one I suggested above, when
our counter was maxed out.
In my earlier message, I was attempting to draw a distinction between
handling allocation failures for trivial objects like pebbles versus failures
for resources required to model NPC knowledge, with respect to how the failure
should be reflected in the game world. To note that handling trivial objects
is even less of a problem than I suggested (since they may not need to be
implemented using dynamic allocation, and, if they are, we can still usually
avoid an allocation failure) serves to broaden this distinction and to
highlight the relative difficulty of dealing with NPC resources.
Vince
Lewis Raszewski
>
> I've been lurking awhile and pondering writing some Java IF
> libraries. While I have immense respect for the people working on
> IF-specific languages, I see a lot of advantages to a well-designed
> Java system. Including new media types would be much easier, for
> instance. It would have decent cross-platform support. (Java: Write
> once, wrong everywhere.) Internationalization would be easy, too.
>
Well, internationalization is more or less the only thing you mention
that other IF languages don't handle very well. Inform is about the best
at international support, and it's still hampered by the fact that it's
not designed for non-english alphabets.
> But the main thing is that it would give more-or-less average users
> the ability to tinker directly with the parser and other things that
> seem hard to get at in Inform.
Um... This is totally wrong. The reason it's hard to tinker with
inform's parser is that the parser is complicated, not that it's in
inform.
>
> My plan was to try for a modular system, where the display, parser,
> and world model were, as much as practical, separated. I've got a
> model in my head that would allow you to simply plug in, say, an
> experimental parser, or a Speech Object + Text-to-speech interface.
>
The display and the parser are totally separate in inform. The model
world is mostly separate as well. The parser's in parser.h, the model
world is implemented by the verb library, and the display is handled by
the interpreter.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"I feel the magic like i never felt before; I imagine that it's always
been
there." -- Belinda Carlisle, I Feel the Magic
joh
Lewis> joh wrote:
>> I've been lurking awhile and pondering writing some Java IF
>> libraries. While I have immense respect for the people working
>> on IF-specific languages, I see a lot of advantages to a
>> well-designed Java system. Including new media types would be
>> much easier, for instance. It would have decent cross-platform
>> support. (Java: Write once, wrong everywhere.)
>> Internationalization would be easy, too.
>>
Lewis> Well, internationalization is more or less the only thing
Lewis> you mention that other IF languages don't handle very
Lewis> well. Inform is about the best at international support,
Lewis> and it's still hampered by the fact that it's not designed
Lewis> for non-english alphabets.
I admit I'm just starting to poke around in the area, but it does seem
to me that if you wanted to include, say, SVG support, you'd have an
easier time doing it with Java, where open libraries for such things
become quickly available.
>> But the main thing is that it would give more-or-less average
>> users the ability to tinker directly with the parser and other
>> things that seem hard to get at in Inform.
Lewis> Um... This is totally wrong.
I stand corrected-- I had formed a mistaken impression.
>> My plan was to try for a modular system, where the display,
>> parser, and world model were, as much as practical,
>> separated. I've got a model in my head that would allow you to
>> simply plug in, say, an experimental parser, or a Speech Object
>> + Text-to-speech interface.
>>
Lewis> The display and the parser are totally separate in
Lewis> inform. The model world is mostly separate as well. The
Lewis> parser's in parser.h, the model world is implemented by the
Lewis> verb library, and the display is handled by the
Lewis> interpreter.
Again, I've only scratched the surface so far, so correct me if I'm
wrong. But despite the separation you point out, there seems to be
some lack of conceptual separation in Inform. The very structure of
the language seems to assume that actions result in printing text to
the display. I understand that some of that is just because
convenience methods have been added for the most common usages. I just
think there are a lot of different places you could draw the lines
between the various components, and having an interpreter written in a
separate language doesn't encourage you to experiment with shifting
the boundaries.
Of course, before embarking on something like this, one ought to get
thoroughly familiar with the systems that already exist. I'm just
getting ahead of myself. And I'm tired of learning new languages for a
while-- I've had to pick up 5 new programming languages for my job in
the past year, plus a couple more I just wanted to try out. At the
moment, Java seems comfortably blah.
Magnus Olsson
joh <j...@bigblueheron.com> wrote:
>But the main thing is that it would give more-or-less average users
>the ability to tinker directly with the parser and other things that
>seem hard to get at in Inform.
Inform's parser is not hard to get at; it's written entirely in
Inform and the source code is part of the Library. The only
hard-coded thing about the parser is the language syntax for
grammar productions.
>My plan was to try for a modular system, where the display, parser,
>and world model were, as much as practical, separated.
Separating the parser from the world model is hard, if not impossible,
since the parser needs access to the world model to disambiguate
effectively. (I'm using the word "parser" in the way it's usually
used in IF, i.e. it performs not only syntactic analysis, but some
semantic analysis as well.)
joh
Magnus> Inform's parser is not hard to get at; it's written
Magnus> entirely in Inform and the source code is part of the
Magnus> Library.
Yes, I've been corrected on that point.
Magnus> Separating the parser from the world model is hard, if not
Magnus> impossible, since the parser needs access to the world
Magnus> model to disambiguate effectively. (I'm using the word
Magnus> "parser" in the way it's usually used in IF, i.e. it
Magnus> performs not only syntactic analysis, but some semantic
Magnus> analysis as well.)
Well, there are degrees of separation. Of course, your parser will at
a minimum need a grammar that includes everything in the game. (Or
maybe not-- you could imagine a twilight zone game where if you try to
"eat caek", rather than complain that you don't see any caek here, it
assigns the name "caek" to a randomly selected object and teleports it
to you. If most of those objects were sufficiently nasty, this might
be a great way to teach spelling.)
As for disambiguation, again there's a question of where you draw the
lines between components. For example, the Nuance speech-recognition
system includes some natural language interpretation, but it doesn't
really try to disambiguate: it returns the "n best" interpretations
(based only on the grammar) and lets the user code (which here
corresponds closer to the "model world") sort it out.
Not that I'm saying that's best. I'm just saying I'd have an easier
time trying different angles like that if I could use a language I use
every day.
On the other hand, I'm sure a lot of people enjoy using an unusual
language for this. I take every opportunity to prototype in Lisp, not
because it has much that you can't get with other languages anymore,
but just because it's wacky and fun.
Please don't think I'm knocking Inform or anything else-- I just said
I was pondering it. I wouldn't have brought it up at all except for
another post on the topic. I appreciate everyone's feedback.
j o h !
Kevin Forchione
news:87wuzg6...@hammurabi.foo.bar...
Oh no, I don't. I just think you're still in the romance-phase with
object-oriented design concepts. :)
--Kevin
Magnus Olsson
That, of course, is no reason to prefer C++ over Inform or TADS :-).
Kevin Forchione
news:9vvral$3cl$1...@news.lth.se...
> In article <W3KU7.19429$Ah.629274@rwcrnsc52>,
> Kevin Forchione <Ke...@lysseus.com> wrote:
> >"joh" <j...@bigblueheron.com> wrote in message
> >news:87wuzg6...@hammurabi.foo.bar...
> >> >>>>> "Magnus" == Magnus Olsson <m...@df.lth.se> writes:
> >
> >> Please don't think I'm knocking Inform or anything else-- I just said
> >> I was pondering it. I wouldn't have brought it up at all except for
> >> another post on the topic. I appreciate everyone's feedback.
> >
> >Oh no, I don't. I just think you're still in the romance-phase with
> >object-oriented design concepts. :)
>
> That, of course, is no reason to prefer C++ over Inform or TADS :-).
Absolutely. And in fact TADS 3 has benefited immensely from a more rigorous
application of OO design patterns.
--Kevin
joh
Kevin> with object-oriented design concepts. :)
Naw, the romance went out of it the first time I had to write a
GUI. If only we didn't have to support users...
Magnus> That, of course, is no reason to prefer C++ over Inform or
Magnus> TADS :-).
Granted, but from where I stand, the question is whether there's some
reason to prefer Inform or TADS over Java or C++. Other than the fact
that most of the work is already done. It seems to me that a library
for Java could do everything that Inform does, but Inform can't do
everything that Java does. Plus, working in Java is honing the skills
that pay the bills.
j o h !
David Thornley
joh <j...@bigblueheron.com> wrote:
>>>>>> "Magnus" == Magnus Olsson <m...@df.lth.se> writes:
>
> Magnus> That, of course, is no reason to prefer C++ over Inform or
> Magnus> TADS :-).
>
>Granted, but from where I stand, the question is whether there's some
>reason to prefer Inform or TADS over Java or C++.
Convenience and portability come to mind.
Other than the fact
>that most of the work is already done. It seems to me that a library
>for Java could do everything that Inform does,
From a programming standpoint, yes. However, you're not going to
run that Java game on a Palm Pilot, which is a feature of zcode
games that some people really like. (Yes, I suppose you could try
to write a Java-to-zcode interpreter, but I don't think this is what
you're proposing.)
Moreover, it's going to be harder to program. Inform and TADS are
not mainstream languages, but have a good deal of quirks that fit
well with IF writing. TADS, for example, doesn't really make a
distinction between class and instance, which isn't how the more
mainstream object-oriented languages have done it, but which cuts
into the amount of extra work the author has to do.
Java doesn't have the syntactic extensions of Common Lisp, or even
of C++. A Java program has to be written in Java (well, duh), and
that includes stuff and structure that is basically irrelevant to IF.
Given the additional superstructure, that's more things to get wrong,
and therefore the program is harder to write.
but Inform can't do
>everything that Java does.
What can't it do that's important in IF?
Plus, working in Java is honing the skills
>that pay the bills.
>
For some people. Many people here are into computers seriously,
and for them learning Java is a good idea. Many are not, but
become competent at Inform or TADS in order to write what they
want to write. The fact that Inform and TADS are easier to
learn to use than Java, in their restricted intended domain,
is very important here.
There are lots of odd little languages that are widely used by
people in given domains, such as SQL and various report generators.
Java could do anything these can do, but would it be a good idea
to try to teach Java to every user of, say, Crystal Reports?
Most of them would use Java for nothing else, so it would be
a frustrating waste of effort.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Kevin Forchione
True. But then Inform is a specialized language for the production of
Interactive Fiction, not a general purpose programming language. TADS source
is written in C++, and I believe Inform is written in C. As such, one could
argue, TADS could incorporate more features of its parent language, but this
would not make it a better language for developing IF.
>Plus, working in Java is honing the skills
> that pay the bills.
When will it be ready for beta?
--Kevin
Lewis Raszewski
It is, however, a reason to prefer smalltalk.
How come no one ever strides in here asking if there's any worth to a
smalltalk IF development system?
That'd actually be neat.
(While I was meandering off about declarative style the other day, it
occurred to me that prolog might be a reasonable language to hammer into
something IFfy. It's already halfway there; your basic prolog session
is: feed a bunch of facts into prolog, then ask it questions about the
world you've built.
Also, prolog is neat because false is, by definition, undefined. And
because if you try to load a buggy program, its response isn't
"mismatched parens at line 74" or "expected semicolon but found major
general". It's "No." How cool is that?)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"Get off my world." -- Brigadier Alistair Gordon Lethbridge-Stewart,
Doctor
Who: Battlefield
Lewis Raszewski
See, this is not true (well, except maybe honing the skillz that pay the
billz, though I've found that my IF work has never really honed any
skills useful outside of IF (excepting GWindows, which made me a
not-totally-incompetent UI designer)); Java is always going to be
clumsier at the things that you do most often in IF, because it's
oriented that way. One example: most of your game world objects are
unique. They exhibit a level of customization beyond what you can get by
just twiddling field values from the Uber Object superclass, yet there's
only one of them, so makeing a class and having to dynamically allocate
one seems redundant. Now, Java has a leg up on C++, in that you can use,
say, an anonymous inner class to declare that sort of thing, but it's
still a lot clumiser to work with than Inform or Tads's equivalent.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"There's so much joy in life, so many pleasures all around, but the
pleasure
of insomnia is one I've never found." -- Barenaked Ladies, Who Needs
Sleep
Garth Dighton
<3C238C75...@hotmail.com>:
>
>(While I was meandering off about declarative style the other day, it
>occurred to me that prolog might be a reasonable language to hammer into
>something IFfy. It's already halfway there; your basic prolog session
>is: feed a bunch of facts into prolog, then ask it questions about the
>world you've built.
>
>Also, prolog is neat because false is, by definition, undefined. And
>because if you try to load a buggy program, its response isn't
>"mismatched parens at line 74" or "expected semicolon but found major
>general". It's "No." How cool is that?)
>
>
There was a PROLOG i-f system mentioned once on this newsgroup, actually,
which led me here:
http://www.amzi.com/AdventureInProlog/index.htm
--
Garth Dighton
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
joh
>>>>> "David" == David Thornley <thor...@visi.com> writes:
>>
Magnus> That, of course, is no reason to prefer C++ over Inform or
Magnus> TADS :-).
>> Granted, but from where I stand, the question is whether
>> there's some reason to prefer Inform or TADS over Java or C++.
David> Convenience and portability come to mind.
...
David> However, you're not
David> going to run that Java game on a Palm Pilot, which is a
David> feature of zcode games that some people really like.
Certainly you can run Java on a palm, and I'd be willing to bet that
more systems, including more palm pilots, have Java VMs on them than
have zcode interpreters. C++, of course, you can port to most
anywhere, with a bit more effort.
David> Moreover, it's going to be harder to program. Inform and
David> TADS are not mainstream languages, but have a good deal of
David> quirks that fit well with IF writing.
I would guess there's a bit of a vicious circle, there,
though. Inform/TADs quirks fit well with IF writing because IF writing
is mostly defined as "creating programs that work like Inform/TADs
games." But see below...
David> Java doesn't have the syntactic extensions of Common Lisp,
David> or even of C++.
Alas, too true.
David> A Java program has to be written in Java
David> (well, duh), and that includes stuff and structure that is
David> basically irrelevant to IF. Given the additional
David> superstructure, that's more things to get wrong, and
David> therefore the program is harder to write.
But for me, and many others, the superstructure of a Java program is
automatic-- it requires no noticeable effort and is easy to debug.
David> but Inform can't do
>> everything that Java does.
David> What can't it do that's important in IF?
Integrate with tons of free libraries. Which ones? What good are they
for IF? I don't know, but I'd like to try to find out.
>> Plus, working in Java is honing the skills
>> that pay the bills.
>>
David> For some people.
...
You seem to think I'm arguing that everyone should abandon Inform and
TADs for my vaporware. I don't. I simply stated that I see many
advantages to using a more general, more widely supported, more widely
known language. I've never yet forced anyone to use any software I've
written.
j o h !
Nils Barth
>How come no one ever strides in here asking if there's any worth to a
>smalltalk IF development system?
Er, someone did back in 1998 (as cited by Plugh! earlier in this
thread), thus spawning a 181-message thread (some of it even relevant):
http://groups.google.com/groups?selm=34F45E77.4476%40surrey.ac.uk
-nils
Kevin Forchione
>
> I would guess there's a bit of a vicious circle, there,
> though. Inform/TADs quirks fit well with IF writing because IF writing
> is mostly defined as "creating programs that work like Inform/TADs
> games."
Or AGT or BASIC or DOS for that matter.
Regardless of the language in which it is written, whether Java, C++,
Inform, TADS, or assembler, an Interactive Fiction game has certain
expectations put upon it by the community of players. These expectations
include the style and presentation of text, the sophistication of the
parser, and the self-consistency of the model world.
It is the expectations of the players that set the standards for Interactive
Fiction games.
Given the nature of the game, there are characteristics of coding as well.
Interactive Fiction is predominantly textual in nature. Game objects are
largely, although not exclusively, singletons. There are large numbers of
"decorations" that make coding a well-defined and self-consistent world
tedious. And IF is not simulation. Exceptions make the rule. Memory and
speed, due to the kinds of machines these games are played on, is still an
important consideration. Response time must be minimized, and there are few
scenarios that would benefit from background processing.
The quirks of any of the specialized IF programming languages tend to take
these characteristics into consideration.
The TADS 3 development group looked at features of Java (as well as other
languages) that might be useful to incorporate. Consequently the language
provides automatic garbage collection of dynamically-created objects; a more
Java-like syntax; try-catch-finally exception handling; Vector, ByteArray,
LookUp Tables, and BigNumber classes; as well as reflection features.
But it addresses the needs of the author with respect to the characteristics
of Interactive Fiction programming. Needs that are driven by the nature of
the game.
Whether it's Java, or something else, if you're going to create a
development system then you'll need to meet the needs of the authors, who in
turn need to meet the needs of the gaming community. On the other hand, if
you're simply going to write a game, well...
Frankly, the IF community will be strengthened by your efforts regardless.
Maybe you'll provide something authors like, maybe something authors will
simply steal from, or perhaps something authors can reminisce on as a
historical footnote in the long list of systems that fell by the wayside.
--Kevin
joh
Thanks, Kevin, for a thoughtful and informative response. You've made
me interested in taking a deeper look at TADS.
I think I'm going to drop the argument here and recloak-- I really
shouldn't have opened my mouth yet, since I'm still just scoping the
scene.
I would like to make an observation, though, about the replies I've
gotten so far. Many people have stated or implied that IF is some sort
of separate realm, and therefore it wouldn't be worthwhile to use a
general-purpose language.
Frankly, that surprises me. I was drawn to this newsgroup because IF
is actually somewhat related to my job. I'm currently working on a
Java application that uses a (separate, commercial) natural language
parser. So naturally I began thinking about how parts of an IF system
could be useful in other applications, and vice versa.
The app I'm working on also happens to be a rewrite of a legacy
application written in a proprietary, specialized language. We have to
abandon it because it's too difficult to integrate with the other
parts of our system. (It's also the worst code ever written, bar none,
but that's another story.)
Well, I think my next step will be to write some small games in TADS
and Inform. Then I'll get back to you.
j o h !
Lewis Raszewski
> Certainly you can run Java on a palm, and I'd be willing to bet that
> more systems, including more palm pilots, have Java VMs on them than
> have zcode interpreters. C++, of course, you can port to most
> anywhere, with a bit more effort.
See, this is a tricky claim. Java was originally written to be a
language for internet appliances, so there's probsably lots of little
dead-end appliances that run it. Java runs, of course, on every major
modern platform. Now, the Z-machine also runs on every major modern
platform. And it runs on every major archaic platform too. I used to
have the full list of things the Z_machine had been ported to, but it
includes cell phones, the Nintendo Game Boy, and lots of other things
that won't run java. Forget internet appliances, the Z-machine will run
on most household appliances.
Now, how big a selling point this should be is debateable. Pocket/Palm
PCs is a big loss for Java, but the "archaic" formats, I'm not so sure.
THough, if computers keep obsoleteing themselves every 18 months,
there's going to be quite a few *million* "uselessly" obsolete machines
lying around in a couple of years.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"We few, we happy few, we band of brothers." -- Shakespeare, King Henry
V
IV.iii
joh
>> Certainly you can run Java on a palm, and I'd be willing to bet
>> that more systems, including more palm pilots, have Java VMs on
>> them than have zcode interpreters. C++, of course, you can port
>> to most anywhere, with a bit more effort.
Lewis> See, this is a tricky claim. Java was originally written to
Lewis> be a language for internet appliances, so there's probsably
Lewis> lots of little dead-end appliances that run it.
You're mistaken. Java was not written for Internet appliances, it was
written to be a cross-platform language, one that runs on desktop
computers as well as "Internet appliances" (Although that term wasn't
in common use then -- Sun was thinking more of Oracle's network
computer flop.) Of course, Java isn't well designed for use in small
machines. The overhead just to run the JVM is way too high. From the
beginning, I think Sun counted on some sort of divine intervention to
make the JVM less demanding. At this point, Java is used more on the
server side, which is the one place its original designers probably
didn't envision it catching on.
It does run on the Palm, though. And it is one of the very few
languages that let you deliver an application to almost everyone with
a Web browser, with no need to step them through an install
procedure. Yes, we all hate applets, but with a little effort and
realistic goals, you can make them work. That's another reason why I
thought a Java IF system might be nice-- there are lots of different
ways you could integrate it into a Web server. I know, there are
existing systems for doing that, but Java really does excel at serving
dynamic Web content.
Lewis> Now, how big a selling point this should be is
Lewis> debateable. Pocket/Palm PCs is a big loss for Java, but the
Lewis> "archaic" formats, I'm not so sure.
I'm not sure what you mean by that last sentence, but you seem to be
implying that Java doesn't run on PDAs. It does. See
http://java.sun.com/j2me/ and
http://java.sun.com/products/midp4palm/index.html . How well it would
perform some of the intensive tasks involved in IF, I don't know.
joh
Ricardo Dague
objects. How the parser is linked to the model world is mainly in how
names of objects match user input.
In general, an object is a better match for input if the name used for
it is longer and it is more suitable in context. That is: How well
does a sequence of words match the object's name? and Does the object
fit better in this place in the sentence?
In my JURT system (http://www.plover.net/~trikiw) I was able to
simplify the connection between parser and model by answering the
first question when forming a list of objects matching words, and then
answering the second after parsing and before the action is performed.
The Factor class is that list. Its constructor shows the input to
everything the player can see, letting each one score the input and
call the nominate() method of Factor, which collects the items with
the best score.
The Action class models the action that's derived. Its getQualValue()
method examines the items in a Factor, returning another score which
is higher for more suitable ones. qualify() in Factor is what calls
getQualValue() on each item. Then toSingle() and toMulti() in Factor
call qualify() and, if necessary, prompt the user for further help in
disambiguating. Those methods generate a single object or more than
one from the Factor.
Another class, Expression, handles lists of noun phrases separated by
commas and "and"s.
...I was able to make this with relatively little code, and code
that's structured.
-- Ricardo
trikiw at netzero dot net
John W. Kennedy
> Also, C++ isn't an IF language. IF languages like Tads, Inform, Hugo,
> and the rest have an insane number of niceties which are there
> *because* this is an IF language. Yes, any real programming language
> afficianado would consider such things cutsey hacks (except possibly
> Perl gurus), but frankly, when what you're doign first and foremost is
> text adventure, it's *hard* to get by without these things. Like, C++
> isn't really good at the sort of circular refernce most IF systems can
> implicitly create: Object X is in room Y. THis means that Object X
> has a field called "parent", which is set to Y, and object Y has a
> field called "child" which is set to X. This is a damned hard thing
> to do in a declarative fashion in C++; you'd most likely end up with a
> huge initialization routine, which would, very likely, be full of
> bugs.
Actually, this would be a trivial application of STL in C++.
> Also, C++ is sort of a ugly, hackish language, chock full of things
> that seemed to someone or other like a good idea at the
> time. polymorphism and multiple inheritance, late binding, etc, are
> all handled in mysterious and bizarre ways in C++.
Multiple inheritance is the only thing that's really strange in C++
(once you've hammered it into your head that a template is not a macro),
and that is by MI's very nature. However, multiple inheritance tends to
be a need in a language without a common root object type, because of
the orthogonal inheritance needs of generalized collection classes and
whatever modeling the program is up to. (All programs outside of pure
system programming and number crunching model _something_; IF is just an
extreme example.)
> It *could* be done. Indeed, I suspect it *has* been done, back in the
> old days when every comapny had their own IF design system.
Not really -- most commercial IF seems to have been done with an ad-hoc
language and an interpreted virtual machine of some sort. (Indeed, the
one commercial IF I know for sure was written in a non-IF language after
the first experimental days is Cyborg, which was written in FORTH, which
A] is based on tiny building-block subroutines, so that FORTH programs
tend to evolve ad-hoc languages anyway, and B] uses an interpreter.)
> The trouble is that, given the difficulties, you'd need a pretty
> damned good reason to actually *do* it. Most of the areas where these
> reasons exist (like, direct access to the computer hardware) are sort
> of orthogonal to most IF.
Raw speed, of course, if that's a consideration, which it might be if
some component of a game actually needed, say, a realistic physics
engine.
But even if I were to decide to do it, I think I'd design a preprocessor
that used an Inform-like declaration language, with embedded C++ code
for object methods. The preprocessor could also enforce 99% of
portability constraints, and, of course, would take care of string
compression.
--
John W. Kennedy
(Working from my laptop)
Kevin Forchione
"David Thornley" <thor...@visi.com> wrote in message
news:tOLU7.2598$aH2.6...@ruti.visi.com...
>TADS, for example, doesn't really make a
> distinction between class and instance, which isn't how the more
> mainstream object-oriented languages have done it, but which cuts
> into the amount of extra work the author has to do.
The object model that TADS uses is prototype-based, rather than class-based.
Languages such as Self and SmallTalk are examples. In TADS, the "class"
keyword is used to distinguish between objects that are treated as traits
for other objects, but are not in the scope of the parser/command execution
mechanism.
--Kevin
Sean T Barrett
>> distinction between class and instance, which isn't how the more
>> mainstream object-oriented languages have done it, but which cuts
>> into the amount of extra work the author has to do.
>
>The object model that TADS uses is prototype-based, rather than class-based.
>Languages such as Self and SmallTalk are examples. In TADS, the "class"
>keyword is used to distinguish between objects that are treated as traits
>for other objects, but are not in the scope of the parser/command execution
>mechanism.
Actually, SmallTalk is class-based. I think technically TADS is
still pretty clearly class-based. (Having classes be objects that
you can send messages to doesn't make something prototype based.
I forget the exact details since I haven't looked at Self in a long time.)
I think the important issue in TADS and other IF languages, as various
people have pointed out at various points in this thread and as I always
trot out for "I'm writing IF in general-purpose-language X", is that IF OO
languages are tailored to having customized, unique objects, where
traditional languages expect all their objects to be basically the same.
I suspect that's sort of what you're thinking about when you say TADS
is prototype-based.
Skilled programmers rapidly learn to make systems data-driven when
they start to involve a lot of variations/exceptions/unique-behaviors.
The next step on the data-driven road people sometimes take is creating
a little interpreted language for expressing data that has some
programmatic functionality. (I've gotten the impression over the
years that Fortran Adventure did this.) I suspect that in any language
that doesn't easily let you configure unique (singleton) objects, you'd
end up with a little mini-language to define them for IF.
SeanB
Xenos
On 14 Dec 2001 01:01:59 -0800, pl...@subdimension.com (Plugh!) wrote:
>Did anyone ever give any thought to writing i-f in C++? I can see the
>obvious advantages of (multiple) inheritance, polymorphism, etc and
>the obvious disadvantage that there isn't, as yet, a standard parser,
>world model, etc but once the parser had been ported and a few classes
>defined for room (from which we derive darkRoom), etc wouldn't we have
>a wonderfully flexible and extensible system?
>
>I suppose that Java would be just as acceptable.
>
>I am prompted to ask this after reading "TADS vs Inform - a (vaguely)
>in-depth comparison" at
>http://www.cs.wisc.edu/~dbs/tads-vs-inform.html
>
>Fell free to tell me there would be no point, as TADS & Inform are all
>that we need ...