Prolog for writing IF?
David Rees
>Has anyone tried using Prolog for writing IF?
>
>--
> The Evil Tofu (Only Human)
There's a beginners Prolog book which teaches the language by guiding
you through the creation of a simple text adventure. Can't remember the name
though. It wasn't a big book if that helps any.
---Dave (re...@cs.bu.edu)
Jerome Chan
(Steve Dunham) wrote:
> It would be nice if somebody who has seen this book could write a
> short example and post it (or put it in the if-archive).
>
> Steve Dunham
> dun...@gdl.msu.edu
I'm going to try writing one ,based on the book, for one of my classes.
I'll post it up once I'm done.
Andrew Lewis Tepper
thing that seems like a (minor) annoyance with TADS is the inability to
create multiple copies of objects, or the ability to create those
objects dynamically. In single player games you can usually program
around it ("There's a yellow marble, a red marble, an a blue marble
here"), but in multiple player games (MUDs) you can't. Also if you
wanted to add non-text elements to a game it would be as easy as buying
an additional library.
Andy
Russell Wallace
Yep, C or C++ with a library of standard routines for the parser etc.
should be pretty much equivalent to TADS in terms of productivity, and
with some advantages in terms of flexibility... the main advantage of
TADS is that it's much less intimidating for the non-programmer to get
into, you don't have to learn C, install a compiler etc.
--
"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwal...@cs.tcd.ie
Michael Van Biesbrouck
Steve Dunham <dun...@cl-next4.cl.msu.edu> wrote:
>Jerome Chan (y...@po.cwru.edu) wrote:
>: Adventure in prolog by Dennis Merrit ISBN
>: 0-387-97315-X/3-540-97315-X. I'm wondering if anyone else has
>: written adventures in prolog? It looks _really_ easy, I'm surprised
>: that I don't see this mentioned in this ng.
>
>It would be nice if somebody who has seen this book could write a
>short example and post it (or put it in the if-archive).
Since writing adventures in Prolog (or other declarative languages)
interests me, I took a look at this book several months ago. It
develops a single (very short) adventure, but uses several different
techniques to implement it.
If I remember correctly, it used Prolog's symbol input facilities to get
the input and didn't have an interesting parser. These two problems
mean that without changing the input structure there were fairly severe
limitations. I think that synonyms, punctuation and sentence structure
were all problems.
The adventure locatations and objects were largely implemented inside
the verbs, so making a new adventure would require rewriting most of the
code. I was also disapointed with the introduction to Prolog that it
provided. Overall, I found it very small-scale in both structure and
vision. Despite these comments, however, this book does appear as a
resource in the Prolog FAQs.
Prolog allows you to take much more general approaches. I suggest that
you try writing a `real' parser (tokenize to symbols, then parse the
symbols into a standard format) and verbs that accept objects. Then you
can implement the adventure as a series of special cases followed by
more generic parts. Something like:
look_at(_):-player_blinded, write("You can't see a thing!"), nl.
look_at(medusa):-here(medusa), kill_off_player("The sight of the
once-lovely woman turns you to stone").
look_at(sun):-blind_player.
look_at(Obj):-here(Obj), visible(Obj), long_description(Obj);
write("You can't see that here."), nl.
This implementation assumes that assert is used in the code, but this is
not necessary (and is very inefficient in some versions of Prolog). For
some implementations, the first and the second half of the last rules
might be required to fail (green cuts), or perhaps everything will
succeed with final cuts.
Predicates like here really should be (or be implemented using)
located_at(Obj, Loc) so that NPCs can run around stealing objects and
the player can command "go to the fountain" and take the shortest known
path for here to there.
The only problem with setting up a Prolog adventure is undo. It
doesn't seem to be a very easy thing to do correctly in an unlimited
way. If you want just one level of undo and are passing the current
state of the adventure to each rule, then sending the old state around
will work.
--
Michael Van Biesbrouck, UW CSC Librarian
gopher://descartes.uwaterloo.ca/h0/mathSOC/.csc/.www/.mlvanbie/homepage.html
Spin-doctors are like evil anti-librarians; they're
the Dark Side of the Force. -- Bruce Sterling
Fredrik Ekman
The only problem with setting up a Prolog adventure is undo.
Well, I still claim that efficiency is a problem. Admitted; my only
experiences with prolog is through MacProlog 3.5 and some ancient
version of Turbo Prolog, but unless there are Prolog implementations
that are extremely more efficient than those, then the mighty
rescue-the-princess-by-hacking-your-way-through-five-hundred-castles
adventure is quite impossible. Actually, even a more realistic
approach, or even a large demo, would make at least MacProlog choke.
And even if it could handle it, it would still be painfully slow,
no matter how many smart cuts and optimization routines you write.
Please prove me wrong. I'd love to be able to write adventures in
Prolog. I just don't think it's practically possible.
/F
Russell Wallace
>In article <1994Mar19.1...@cs.tcd.ie>, rwal...@cs.tcd.ie (Russell
>Wallace) wrote:
>> Yep, C or C++ with a library of standard routines for the parser etc.
>> should be pretty much equivalent to TADS in terms of productivity, and
>> with some advantages in terms of flexibility... the main advantage of
>> TADS is that it's much less intimidating for the non-programmer to get
>> into, you don't have to learn C, install a compiler etc.
>Okay, so what sort of functionality should be in a library?
>Object:=
>Rooms,
>Characters,
>Items.
I'd say, a parser, routines for standard stuff like saving and restoring
the game state, and maybe example code for commonly used kinds of
objects like is provided with TADS. Actually, when you get down to it
all these could also be obtained by getting a copy of an adventure
someone else has written in C.
Jerome Chan
> Yep, C or C++ with a library of standard routines for the parser etc.
> should be pretty much equivalent to TADS in terms of productivity, and
> with some advantages in terms of flexibility... the main advantage of
> TADS is that it's much less intimidating for the non-programmer to get
> into, you don't have to learn C, install a compiler etc.
Okay, so what sort of functionality should be in a library?
Object:=
Rooms,
Characters,
Items.
??
Dimwit Flathead
the user's environment would get a chance to react to any action
that is witnessed.
How would you design a library, though, that would allow for adventures
like King's Quest, etc??
Hmm, anyone know where I should look for handling mouse input on
Unix based systems??
John Viega
Michael Van Biesbrouck
Fredrik Ekman <d9...@krokis.pt.hk-r.se> wrote:
>Well, I still claim that efficiency is a problem. Admitted; my only
>experiences with prolog is through MacProlog 3.5 and some ancient
>version of Turbo Prolog, but unless there are Prolog implementations
[There was only one version of Turbo Prolog ... it was bought from
Borland a few years ago and underwent a name change.]
>that are extremely more efficient than those, then the mighty
>rescue-the-princess-by-hacking-your-way-through-five-hundred-castles
>adventure is quite impossible. Actually, even a more realistic
>approach, or even a large demo, would make at least MacProlog choke.
>And even if it could handle it, it would still be painfully slow,
>no matter how many smart cuts and optimization routines you write.
>
>Please prove me wrong. I'd love to be able to write adventures in
>Prolog. I just don't think it's practically possible.
There are far more efficient versions of Prolog available, and the FAQ
for comp.lang.prolog will point you to a horde of them. I can't prove
you wrong because I haven't finished my work on my own version of Prolog
for writing IF in (making certain assumptions and optimizations because
of the special purpose). I want to redesign the interpreter before
continuing the coding. Since my Prolog-like code is written for a
completely different syntax, I cannot quickly provide a demonstration.
I suggest you read
ftp://ai.uga.edu/pub/ai.reportsd/ai198908.ps.Z
if you still have problems with efficiency.
However, there still is one area in which Prolog implementations tend to
have problems (get ready to skewer me for this): strings. Technically,
in Prolog a string is represented as a list of single character values
... this means that a room description might take 8 times the space it
should. Some implementations attempt to address this issue by providing
constant strings (using a different style of quote).
Most of the things that you will need to do can be accomplished with a
ASCIIZ string ("Hello\000") and a non-copying (memory usage efficient)
implementation of Prolog in a trivial manner. However, programmers
might want to have all of power of Prolog strings at their disposal
and begin building lists from the bottom up instead of just taking the
first n elements off. The model becomes complicated in one of two ways
(as far as I can figure out). A data copying implementation will work
fairly inefficiently on ASCIIZ strings, but is not complicated by this
addition. The inefficiencies are both in time and memory.
Calling the C function strcat() in the middle of a Prolog program
(ASCIIZ implementation, of some sort) would solve all of these problems.
Hopefully there is a Prolog implementation other than Turbo Prolog that
does this or something equivalent.
I don't think this message was very clear. I drew random bits from my
(imperfect) knowledge of Prolog implementation and added odds and ends
from my own notes on the string problem. If you ask for clarification
on specific parts, I will greatly elaborate.