"Medieval Apprentice" Prolog text adventure
Kellogg Patrick Layne
adventure in Prolog. I was taking a graduate level computer
science theory course and an artificial intelligence course.
In the game "Medieval Apprentice", you can control six
different characters: a witch, a nun, a princess, a
blacksmith, a squire, and an urchin (two male, and two
female). The idea was that all the action would take
place during one day, and the player could go back
and forth, choose different characters at different
times.
For example, at 8:00, you could control the squire,
and have him "RIDE HORSE" and "GO NORTH" to a meadow.
Let's say there is a spellbook hidden in the grass.
He could take the book and go to the tower where the
witch lives. Meanwhile, you could go back to 8:00 and
control the witch. At 8:15, the witch takes the book
from the squire and goes to the castle. By reading
the book, the witch casts a spell, killing the
evil prince... gaining 20 points.
Squire Witch Evil Prince
------ ----- -----------
8:00 Go to meadow Do something Do something
8:05 Get book etc. etc.
8:10 Go to tower etc. etc.
8:15 Give book Take book etc.
8:20 Do something Go to castle etc.
8:25 etc. Read spell Die
Now, if the squire never rode to the meadow at 8:00,
hw couldn't get the book. Then, the witch couldn't
read the spell, and the whole chain of actions
is invalidated. Ideally, the game would be a sort of
puzzle, where you figure out what chain of actions
results in the ideal state at midnight (the evil
prince is dead, the king hasn't been assasinated,
the village hasn't been overrun by Mongols).
Ten years ago, I tried to write this game in C. I
failed miserably, because I had hundreds of linked
lists that tried to keep track of "a day in the
life of X"... whether X was a spellbook, a witch,
or a building. Changing an action at 10:00 caused
a *huge* cascade of linked list inserts and deletes.
Last month, I recycled the idea using Prolog. SWI
Prolog turned out to be a lot of fun. I wrote simple
"Horn form" clauses that looked like this:
%Example of some clauses
state(s0).
state(s1).
state(s2).
nextstate(s0,s1).
nextstate(s1,s2).
actualtime(s0,'8:00').
actualtime(s1.'8:05').
actualtime(s2,'8:10').
object(bottle).
atobject(bottle,s0,blacksmith_shop).
place(blacksmith_shop).
%Getting drunk
possibleaction(PERSON,STATE,drink) :- has(PERSON,STATE,bottle),person(PERSON),state(STATE).
drunk(PERSON,STATE) :- drink(PERSON,STATE,bottle),person(PERSON),state(STATE).
drunk(PERSON,NEXTSTATE) :- nextstate(STATE,NEXTSTATE),drunk(PERSON,STATE),person(PERSON),state(STATE).
%Object permanence
atobject(NEXTSTATE,PLACE,OBJECT) :- nextstate(STATE,NEXTSTATE),atobject(OBJECT,STATE,PLACE),object(OBJECT),place(PLACE),not(objec
tchange(STATE,OBJECT)).
% ^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^
Hopefully, this code fragment gives an idea of what I was trying to do.
For example, I could ask SWI-PROLOG the query:
possibleaction(wizard,s2,X).
...and X would be instantiated only to actions that could be performed. If the wizard
isn't holding a bottle at state "s2", then that action won't show up in a list of actions.
I liked this idea, since I was tired of text adventures that allowed you to type
"GET BOOK", only to say "I SEE NO BOOK HERE...". Fellow gamers might know what I'm
complaining about.
One big snag I ran into was that creating new rules forced me to change a lot of rules
that were working. For example, above, when a character gets drunk, they stay
drunk forever. Allowing them to sober up would require a change in the rule. Note the
"objectchange" comment marked with ^^^ symbols under the "Object permanence" section.
(sorry about the text wrap). This was an emergency kludge that I needed to add,
since without it... objects that were in the tower at state "s0" were in the tower
for any future state. You couldn't take an object or destroy it. This addition
also required me to add rules that set and cleared the "objectchange" flag.
objectchange(NEXTSTATE,OBJECT) :- nextstate(NEXTSTATE,STATE),destroy(OBJECT,STATE),object(OBJECT).
Another problem writing a GUI. A sample screen mock-up is at:
http://www.dimensional.com/~kellogg/apprentice/summary.htm
http://www.dimensional.com/~kellogg/apprentice/blacksmith.htm
(...note, there pages use *.BMP pictures that don't show upon
some browsers, Also note that none of the buttons actually work)
Overall, this was a fun final project, and I got an "A" in both classes.
However, I'm disappointed that I didn't finish a polished, working
game. This was my first attempt at writing Prolog (aside from a little logic
puzzle I wrote for a Intro to programming class), but I'm not sure
if this idea warrants further work. Next semester, I'm taking a Natural
Language Processing class and first-year French. I thought I'd use
SWI-PROLOG to combine the two interests and write a Prolog verb-subject
parser for French. Or some other project (ideas are welcome)!
Please let me know what you think. I've never seen a Prolog program
like this before. However, I think the use of Prolog as a game
engine is promising... and not just othello or tic-tac-toe, which
work well. In the end, the big limitation was my imagination... once
I create the wizards, knights, and dragons... I ran out of ideas
for waht actions they could perform and what the actions accomplished.
I guess that's why there are good, highly paid science-fiction writers and I'm
unfortunately not one of them!
Thanks,
Patrick Kellogg
kel...@dimensional.com
http://www.dimensional.com/~kellogg (personal)
http://www.cs.colorado.edu/~kelloggp (school)
Phil Goetz
You can see my page on Prolog for IF at
http://www.cs.buffalo.edu/~goetz/prolog.html
Note the way I get around the problem of Prolog wanting to be
a monotonic logic (the problem you refer to below) by using a
STRIPS formalism.
But apparently nobody is interested in using logic programming for AI,
since no one responded to my message offering to pay thousands of
dollars for someone to write a short game using logic programming.
Phil Goetz
In article <386a...@cs.colorado.edu>,
Kellogg Patrick Layne <kell...@oc.cs.colorado.edu> wrote:
>%Object permanence
>atobject(NEXTSTATE,PLACE,OBJECT) :- nextstate(STATE,NEXTSTATE),atobject(OBJECT,STATE,PLACE),object(OBJECT),place(PLACE),not(objec
>tchange(STATE,OBJECT)).
>
>One big snag I ran into was that creating new rules forced me to change a lot of rules