[Inform] Idea: XML 2 Inform Script
Happy Poster
but the constructs of it were not as clean as I would have liked. The
Designer's Manual could also use a rework so that it wasn't so literary, but
allows one to use it like a manual where you can peruse the constructs of
the language in the same way that Microsoft's msdn library allows one to
drill down the object model for Active Data Objects (ADO), which is a
database interface. I found I had to dig and dig and dig for information in
the Designer's Manual.
However, I don't want to sway from Inform because I love the compiler, I
love the result, I love its power, and I love the availability of zcode
interpreters.
Then, I attended XML 99 in Philadelphia this year and I had an epiphany. The
idea came along to me that one could write an XML schema standard (use XML
Schemas instead of DTDs because DTDs are going away) for Inform-like files.
It would look similar to Inform, but use XML. Then, one could run the XML
through a translator to build the Inform script. Then, they could use the
Inform compiler to compile that into zcode. The entire translation and
compiling process could be made into another executable too. In that sense,
one wouldn't need to know the oddities of the Inform language--they would
just need to know the XML standard, which is cleaner and more elegant, imho.
Example of Inform Script [before XML conversion]:
================================
Object television "portable television set" lounge
with name "tv" "television" "set" "portable",
before
[; SwitchOn: <<SwitchOn power_button>>;
SwitchOff: <<SwitchOff power_button>>;
Examine: <<Examine screen>>;
],
has transparent;
Object -> power_button "power button"
with name "power" "button" "switch",
after
[; SwitchOn, SwitchOff: <<Examine screen>>;
],
has switchable;
Object -> screen "television screen"
with name "screen",
before
[; Examine: if (power_button hasnt on) "The screen is black.";
"The screen writhes with a strange Japanese cartoon.";
];
Example of XML Script translation:
================================
<object name="television" literal="portable television set" parent="lounge">
<aliases>
<alias>tv</alias>
<alias>television</alias>
<alias>set</alias>
<alias>portable</alias>
</aliases>
<attributes>
<transparent/>
</attributes>
<before-parsing>
<switchon>switchon power_button</switchon>
<switchoff>switchoff power_button</switchoff>
<examine>examine screen</examine>
</before-parsing>
</object>
<object name="power_button" literal="power button" parent="television">
<aliases>
<alias>power</alias>
<alias>button</alias>
<alias>switch</alias>
</aliases>
<attributes>
<switchable/>
</attributes>
<after-parsing>
<switchon>examine screen</switchon>
<switchoff>examine screen</switchoff>
</after-parsing>
</object>
<object name="screen" literal="television screen" parent="television">
<aliases>
<alias>screen</alias>
</aliases>
<before-parsing>
<examine>
if (power_button hasnt on)
"The screen is black.";
"The screen writhes with a strange Japanese cartoon.";
</examine>
</before-parsing>
</object>
See how much cleaner this is?
Happy Poster
Philip Goetz
Sent: Tuesday, December 28, 1999 1:37 PM
This is interesting, but I don't understand what you want to accomplish.
The text says you want to convert from XML to Inform; the example
shows you converting from Inform to XML. What do you want to do
that you can't do with the all-Inform approach? It sounds like you want
to use XML to build a preprocessor, which sounds extreme to me;
there are already preprocessors you could use to convert pseudo-Inform
to Inform.
Phil Goetz
pgo...@i-a-i.com
Happy Poster
Huh. Never heard of these preprocessors. Yep. That's what I want. I want to
write something that follows XML standards but looks sort of like
psuedo-Inform, then run it through a preprocessor to convert it to Inform.
As for that being "serious". I don't think so. XML DTD and/or XML Schema
processing code is already in place to load the document object in memory
for perusal. At that point, one could write it out in proper Inform language
and feed it to the compiler.
Happy
Sean T Barrett
>Then, I attended XML 99 in Philadelphia this year and I had an epiphany. The
>Inform-like files.
[..snip..]
>one wouldn't need to know the oddities of the Inform language--they would
>just need to know the XML standard, which is cleaner and more elegant, imho.
And designed to be output by a computer. And being evolved by
committee, and growing more baroque and complex by the day.
Anyway, the relevent bit to this comment can be found at
http://www.w3.org/TR/1998/REC-xml-19980210#sec-origin-goals
i.e. the comment "XML documents should be human-LEGIBLE" (stress
mine) and "Terseness in XML markup is of minimal importance".
I'm pretty sure I had previously found a rationalization explaining
this on the w3 web site (specifically http://www.w3.org/XML/),
but I can't find it anymore in the reams of stuff there.
The inform syntax is clumsy in a number of ways (nothing personal
Graham; even the authors of awk admit to some failings in their
first language), and I'd be all for a more regular syntax. On the
other hand, it also provides some important idioms and conciseness
that would be missing from a "pure" syntax like XML. (In truth,
XML's syntax isn't anywhere near as clean as it could be if it
weren't designed to be compatible with SGML.)
Sean Barrett
David Cornelson
news:nSba4.117541$5W2.3...@news6.giganews.com...
> > Huh. Never heard of these preprocessors. Yep. That's what I want. I want
> to
> > write something that follows XML standards but looks sort of like
> > psuedo-Inform, then run it through a preprocessor to convert it to
Inform.
> > As for that being "serious". I don't think so. XML DTD and/or XML Schema
> > processing code is already in place to load the document object in
memory
> > for perusal. At that point, one could write it out in proper Inform
> language
> > and feed it to the compiler.
>
>
This has me thinking. I've been supposing an Inform IDE for several years
now, but have always backed off because of certain technical mountains,
namely converting the Inform language to and from a database. The reason
being that you would want a relational view of the inform code in order to
display it in an IDE properly and efficiently. Well, I would anyway.
As a data transport tool XML can add some nice compatibility, but my guess
is that this is something that will eventually be hidden from developers and
we'll just be using tools that use XML to talk to each other.
But that begs the question, why couldn't I write a couple of functions, one
to do an Inform to XML translation and then an XML to relational database
translation? There are already tools to programmatically encode and decode
XML trees, so I wouldn't have to create the actual XML organization. Heck, I
wouldn't even have to write XML tags.
Oops. I forgot. The reason I haven't done anything is that I need a nice
clean way to read the Inform language. The first rule for an IDE to be able
to translate Inform into itself would be that the code had no bugs.
Exporting the incomplete code would also result in using some sort of
embedded comment syntax to help my translation routines know what to do. But
once it's tampered with, ah well...another rat's nest.
I've been through the technical mumbo jumbo for Inform and it's not exactly
light reading.
If I could only get someone to build an Inform to XML function....
Jarb
Volker Lanz
to
> write something that follows XML standards but looks sort of like
> psuedo-Inform, then run it through a preprocessor to convert it to Inform.
> As for that being "serious". I don't think so. XML DTD and/or XML Schema
> processing code is already in place to load the document object in memory
> for perusal. At that point, one could write it out in proper Inform
language
> and feed it to the compiler.
Huh? Why? Why would anyone want to do that? I don't get it.
- v
Andy Leighton
>Phil,
>
>Huh. Never heard of these preprocessors. Yep. That's what I want. I want to
>write something that follows XML standards but looks sort of like
>psuedo-Inform, then run it through a preprocessor to convert it to Inform.
>As for that being "serious". I don't think so. XML DTD and/or XML Schema
>processing code is already in place to load the document object in memory
>for perusal. At that point, one could write it out in proper Inform language
>and feed it to the compiler.
Well you wouldn't even have to write hand-coded programs to read the XML
into memory, apply the transorms and write it out as Inform. You should
be able to do all of the above with XSLT. If Happy Poster is interested
he should take a look at a program called XT (http://www.jclark.com/xml/)
As to why you would want to do this? I could think of a couple of reasons.
Firstly, the source could be more portable to any successor to Inform (if
the XML schema was not too tightly based around the extant Inform language).
Secondly, higher level design tools could be written, which would output
the XML. For instance, from time to time people wibble on about easier
tools to develop the rooms and routes between them. If a hypothetical
graphical tools was developed to do this which spat out XIFL [Extensible
Interactive Fiction Language :-)]. This could be processed by the
appropriate XSLT stylesheet to produce Inform, TADS, Hugo or whatever
code you like.
--
Andy Leighton => an...@azaal.dircon.co.uk
"... January is your third most common month for madness" - _Sarah Canary_
BrenBarn
>graphical tools was developed to do this which spat out XIFL [Extensible
>Interactive Fiction Language :-)].
From,
Brendan B. B. (Bren...@aol.com)
(Name in header has spam-blocker, use the address above instead.)
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Happy Poster
designed for IF. Then, one could run it through a function to make either a
TADS, Inform, Hugo, or various other interactive fiction language. The sad
thing, though, is that it couldn't keep up with the powerful potentials of
all 3 of these languages, and would probably get out of date. But if we had
an XML that at least got it to Inform, many others could learn to port that
to TADS, Hugo, etc.
Happy Poster
--
> Firstly, the source could be more portable to any successor to Inform (if
> the XML schema was not too tightly based around the extant Inform
language).
>
> Secondly, higher level design tools could be written, which would output
> the XML. For instance, from time to time people wibble on about easier
> tools to develop the rooms and routes between them. If a hypothetical
> graphical tools was developed to do this which spat out XIFL [Extensible
Ross Presser
(BrenBarn).wrote.posted.offered:
>>If a hypothetical
>>graphical tools was developed to do this which spat out XIFL
>>[Extensible Interactive Fiction Language :-)].
> I think we should call it EIFL, as in "The EIFL tower" :-).
There's already a language called Eiffel.
--
Ross Presser
ross_p...@imtek.com
"And if you're the kind of person who parties with a bathtub full of
pasta, I suspect you don't care much about cholesterol anyway."
David Cornelson
news:8EAB8BB1...@199.45.45.11...
> alt.distingui...@aol.comRemove
> (BrenBarn).wrote.posted.offered:
>
Just for kicks I translated a SpeedIF game (minus the bulk of my objects)
that I wrote into an example XML document.
Of course there would need to be some consensus on the logic of the XML
tags, I wouldn't assume to be an expert, so take this translation as a first
draft. But it all works. I pulled this document into a Visual Basic XML
object and it translates fine. I could easily write this to a database and
develop a visual editing tool. I could then easily write out the database to
XML.
The hard part is the translation XML to Inform and Inform to XML.
Jarb
<INFORM file="sp6.inf">
<COMMENT> ------------------------------------------------------------------
------------</COMMENT>
<COMMENT> SP6.INF</COMMENT>
<COMMENT></COMMENT>
<COMMENT> Write a game that consists of the following: One of the locations
is an iceburg.</COMMENT>
<COMMENT> Mr. Potato Head is an important subject, a magical Top Hat is
found somewhere and</COMMENT>
<COMMENT> you also need to involve a roller coaster. Extra points for
including a reporter,</COMMENT>
<COMMENT> slinky, barbie, bedknob, sunglasses, a beach, or hiking in the
woods. Finally, you</COMMENT>
<COMMENT> need to include, somehow, the following poem:</COMMENT>
<COMMENT></COMMENT>
<COMMENT> Sandra's seen a leprechaun,</COMMENT>
<COMMENT> Eddie touched a troll,</COMMENT>
<COMMENT> Laurie danced with witches once,</COMMENT>
<COMMENT> Charlie found some goblins' gold.</COMMENT>
<COMMENT> Donald heard a mermaid sing,</COMMENT>
<COMMENT> Susy spied an elf,</COMMENT>
<COMMENT> But all the magic I have known</COMMENT>
<COMMENT> I've had to make myself. - Shel Silverstein</COMMENT>
<COMMENT> ------------------------------------------------------------------
------------</COMMENT>
<WS></WS>
<CONSTANT name="Story" type="string">SpeedIF6 - A Top Hat for
Eddie</CONSTANT>
<CONSTANT name="Debug" type="function"></CONSTANT>
<WS></WS>
<CONSTANT name="Headline" type="string"><NEWLINE></NEWLINE>SpeedIF
6<NEWLINE></NEWLINE>by David A.
Cornelson<NEWLINE></NEWLINE><NEWLINE></NEWLINE></CONSTANT>
<WS></WS>
<SERIAL>991126</SERIAL>
<WS></WS>
<RELEASE>1</RELEASE>
<WS></WS>
<REPLACE>DrawStatusLine</REPLACE>
<WS></WS>
<INCLUDE>Parser</INCLUDE>
<INCLUDE>VerbLib</INCLUDE>
<INCLUDE>WhoWhat</INCLUDE>
<WS></WS>
<COMMENT></COMMENT>
<COMMENT> No score or turns...this is FICTION baby</COMMENT>
<COMMENT></COMMENT>
<FUNCTION name="DrawStatusLine" width="arg" posa="arg" posb="arg">
<MACHINE name="split_window" value="1"></MACHINE>
<MACHINE name="set_window" value="1"></MACHINE>
<MACHINE name="set_cursor" row="1" col="1"></MACHINE>
<STYLE type="reverse"></STYLE>
<SETVAR name="width" type="numeric" value="0->33"></SETVAR>
<SETVAR name="posa" type="numeric" value="width-26"></SETVAR>
<SETVAR name="posb" type="numeric" value="width-13"></SETVAR>
<SPACES value="width"></SPACES>
<MACHINE name="set_cursor" row="1" col="2"></MACHINE>
<PRINT cast="name" type="variable">location</PRINT>
<MACHINE name="set_cursor" row="1" col="1"></MACHINE>
<STYLE type="roman"></STYLE>
<MACHINE name="set_window" value="0"></MACHINE>
</FUNCTION>
<WS></WS>
<WS></WS>
<COMMENT>-------------------------------------------------------------------
------------</COMMENT>
<COMMENT> Initialise</COMMENT>
<COMMENT>-------------------------------------------------------------------
------------</COMMENT>
<WS></WS>
<FUNCTION name="Initialise">
<WS></WS>
<CALL name="ChangePlayer"><ARG name="MrPotato"
type="object"></ARG></CALL>
<SETVAR name="location" type="numeric" value="Iceburg"></SETVAR>
<WS></WS>
<PRINT type="string">
<NEWLINE></NEWLINE>It's damn cold out here and you wish someone
would have given you
more to wear than this damn tophat. All you remember is bouncing
along the iceburg and ending up face down in the snow. The worst
part is that you seem to have lost an ear, an eye, and your mouth.
Luckily, you still have your nose, a usable eye, and two feet....
<NEWLINE></NEWLINE><NEWLINE></NEWLINE>
</PRINT>
<WS></WS>
</FUNCTION>
<WS></WS>
<WS></WS>
<COMMENT>-------------------------------------------------------------------
------------</COMMENT>
<COMMENT> Objects</COMMENT>
<COMMENT>-------------------------------------------------------------------
------------</COMMENT>
<WS></WS>
<OBJECT name="LightObj" short_name="Light Object">
<PROPERTY name="name" type="name"><WORD>light</WORD></PROPERTY>
<PROPERTY name="found_in"><FUNCTION><RTRUE></RTRUE></FUNCTION></PROPERTY>
<ATTRIBUTES LIGHT="" SCENERY=""></ATTRIBUTES>
</OBJECT>
<WS></WS>
<INCLUDE>Grammar</INCLUDE>
<VERB name="xyzzy" usage="" function="Xyzzy"></VERB>
</INFORM>
David Cornelson
news:FaLa4.6788$_%5.1...@news1.mco...
> David Cornelson <dcorn...@placet.com>
>
> > The hard part is the translation XML to Inform and Inform to XML.
> >
> > Jarb
>
>
> Pretty neat stuff, huh? Were you at XML 99 in Philadelphia too? Your work
>
My VB work would be for a Win32 Visual Inform. I have no ability to write
anything in Java or any other lower level cross-platform language. It has
been noted in the past that a visual editor need not be cross-platform, only
that the results be exportable somehow to a text file version that is
compilable and readable.
> You should do a search in the FAQ for something I found very useful called
Been there many times. I understand the inform guts to some degree. The
trick is the translation. Graham uses a one-pass method that actually
creates the Z5 file on the fly. I think it would take some major tweaking to
create routines that were capable of XML extensions. The skill level
required for this is likely in the Graham Nelson/Andrew Plotkin range. We
have other people with those skills, but no one seems to be passionate
enough to undertake the project. They all agree though that the idea is
relatively sound.
Jarb
David Cornelson
news:slrn86n5nv...@azaal.dircon.co.uk...
> On Thu, 30 Dec 1999 10:50:46 -0500, Happy Poster <ha...@poster.com> wrote:
> >David Cornelson <dcorn...@placet.com>
> >>
> Hm, I don't like VB, can't run it at home. Zarf uses Macs (I think), he
> won't be able to run your VB program. On a technical note, MS only
provide
> a DOM implementation for VB (there is no event based parser), the MS XSL
> implementation is woefully outdated.
>
> I would recommend Python or Java. These are cross-platform languages
> with strong XML support.
See my reply to Happy.
>
> >I would think one could write an XML2Inform and Inform2XML tool in VB
> >fairly easily,
>
> I would be willing to help write a XML->Inform using XSL.
> However, I think you are putting the cart before the horse.
>
> First we should agree what the XML should look like.
> We probably ought to use a namespace so that some of our tags do not
> get confused with similarly named ones in other namespaces.
I agree. The XML tags that we decide to use would need to be drafted and
reviewed by several people until we cover the exent of the Inform compiler.
There are places where we could all choose to use different XML tags.
For instance, in my previous example, I created <FUNCTION>....
<FUNCTION NAME="Room">
<PROPERTY NAME="name">room</PROPERTY>
<PROPERTY NAME="description">My room.</PROPERTY>
<PROPERTY NAME="before"></PROPERTY>
<ATTRIBUTE><WORD>Light</WORD></ATTRIBUTE>
</FUNCTION>
But someone may decide that it should be implemented differently...
<FUNCTION>
<WITH>
<NAME>room</NAME>
<DESCRIPTION>My Room.</DESCRIPTION>
<BEFORE></BEFORE>
</WITH>
<HAS Light="True"></HAS>
</FUNCTION>
Which one is the right way to go?
Jarb
Happy Poster
> Just for kicks I translated a SpeedIF game (minus the bulk of my objects)
> that I wrote into an example XML document.
>
> Of course there would need to be some consensus on the logic of the XML
> tags, I wouldn't assume to be an expert, so take this translation as a
first
> draft. But it all works. I pulled this document into a Visual Basic XML
> object and it translates fine. I could easily write this to a database and
> develop a visual editing tool. I could then easily write out the database
to
> XML.
>
> The hard part is the translation XML to Inform and Inform to XML.
>
> Jarb
Jarb,
Pretty neat stuff, huh? Were you at XML 99 in Philadelphia too? Your work
looks good to me. I also prefer using Visual Basic because people can port
from that easily (they can read it easier than they can C, Java, Perl, or
Tcl). I would think one could write an XML2Inform and Inform2XML tool in VB
fairly easily, then post the source so that it could be ported on other
platforms. I would do it myself, but am short on time since I have 2 kids
and a crazy job.
You should do a search in the FAQ for something I found very useful called
the Informary. It shows the taxonomy of the Inform language and has been
long overdue. I also hear a rumor that the DM will be rewritten again.
There's a particular problem that runs through the DM. It's hard to
describe. The problem is that we begin talking about the taxonomy of the
Object statement and then it breaks down into digressions and never really
shows you all the pieces in one central place. To get the real answer, you
have to jump around quite a bit in the DM. I converted the DM to a CHM file
(Microsoft's new help format) and attached an automatic keyword index to it.
This allows me to type in keywords and get what I want from the DM, although
I still have to dig. Now that I know the Informary is out, I can get my
answers faster and it has links to a more detailed DM explanation.
Happy
Andy Leighton
>David Cornelson <dcorn...@placet.com>
>>
>
>from that easily (they can read it easier than they can C, Java, Perl, or
>Tcl).
Hm, I don't like VB, can't run it at home. Zarf uses Macs (I think), he
won't be able to run your VB program. On a technical note, MS only provide
a DOM implementation for VB (there is no event based parser), the MS XSL
implementation is woefully outdated.
I would recommend Python or Java. These are cross-platform languages
with strong XML support.
>I would think one could write an XML2Inform and Inform2XML tool in VB
>fairly easily,
I would be willing to help write a XML->Inform using XSL.
However, I think you are putting the cart before the horse.
First we should agree what the XML should look like.
We probably ought to use a namespace so that some of our tags do not
get confused with similarly named ones in other namespaces.
--
Andy Leighton
David Cornelson <dcorn...@placet.com> wrote:
>"Andy Leighton" <an...@azaal.dircon.co.uk> wrote in message
>>
>> We probably ought to use a namespace so that some of our tags do not
>> get confused with similarly named ones in other namespaces.
>
>reviewed by several people until we cover the exent of the Inform compiler.
>There are places where we could all choose to use different XML tags.
>
>For instance, in my previous example, I created <FUNCTION>....
>
><FUNCTION NAME="Room">
> <PROPERTY NAME="name">room</PROPERTY>
> <PROPERTY NAME="description">My room.</PROPERTY>
> <PROPERTY NAME="before"></PROPERTY>
> <ATTRIBUTE><WORD>Light</WORD></ATTRIBUTE>
></FUNCTION>
>
>But someone may decide that it should be implemented differently...
>
><FUNCTION>
> <WITH>
> <NAME>room</NAME>
> <DESCRIPTION>My Room.</DESCRIPTION>
> <BEFORE></BEFORE>
> </WITH>
> <HAS Light="True"></HAS>
></FUNCTION>
>
>Which one is the right way to go?
Well I would go for something like the following (adapted from museum.inf)
<xifl:room name="basement">
<xifl:name>Museum Basement</xifl:name>
<xifl:desc>Once Room 17, this space has been abandoned by the curators who
have simply sprayed its walls with moth-repellant and abandoned it.
</xifl:desc>
<xifl:exits>
<xifl:up>Foyer</xifl:up>
</xifl:exits>
<xifl:before verb="smell">Napthalene</xifl:before>
</xifl:room>
Also we could have
<xifl:function name="ClapSub">
"You clap.";
</xifl:function>
<xifl:grammar>
<xifl:grammarItem>
<xifl:verb>clap<xifl:verb>
<xifl:action target="ClapSub"/>
</xifl:grammarItem>
</xifl:grammar>
Obviously I do not think that we could cope with the entire complexity
of the Inform programming language. But I think that it is possible
that we could cover enough to be useful.
Obviously I based this around Inform, but I believe the above could
be machine translated to Hugo and Jacl (I haven't looked at TADS enough
to comment).
Happy Poster
know if they sound good.
1. Sounds like we need something that is platform-transparent (Inform, TADS,
etc.), but I fear that when you go down that avenue you end up with watered
down games that do the least-common denomenator of all the platforms. We
should probably just stick to an Inform-like schema and let others make
something for the other platforms. Eventually there might be slim chance of
another phase where the schemas start to blend into one naturally. At least
by shooting for XML, it increases the odds of that happening.
2. I think the XML Schema should be easier to use than Inform script. By
that, I mean that instead of having an object statement that starts off
oddly like:
object computer_name "literal name" parent_name
we break this out into something that people can understand better, like:
<object name="computer_name" title="literal name">
<parent>parent_name</parent>
...
</object>
This way, we move from placement delimiters to tag and attribute delimiters
for the language taxonomy.
3. I think when it comes to some sections of code, such as:
if (player has dog) {
print "very good";
} else {
print "nope";
};
We are better off sticking that in a code block inside the XML then
rewriting it. This is possible, but tricky, if you use the correct DTD (use
that for now, switch to XML Schemas later).
Happy
David Cornelson
> No matter how we do this, I think we should have core goals in mind. Let
me
> know if they sound good.
>
> 1. Sounds like we need something that is platform-transparent (Inform,
TADS,
> etc.), but I fear that when you go down that avenue you end up with
watered
> down games that do the least-common denomenator of all the platforms. We
> should probably just stick to an Inform-like schema and let others make
> something for the other platforms. Eventually there might be slim chance
of
> another phase where the schemas start to blend into one naturally. At
least
> by shooting for XML, it increases the odds of that happening.
>
Well, I think there's a compromise here. We could segment much of the work
by language, but there are many common threads between all of the languages,
such as includes, grammar, objects, properties, attributes, etc. The
difference is mostly TADS, (assuming we all agree that Hugo and Inform are
sufficiently similar).
But I agree, starting with one language, then normalizing it later would be
more productive. But the best scenario would be to have a group of people
work on each language and coordinate the functionality of common tags.
> 2. I think the XML Schema should be easier to use than Inform script. By
> that, I mean that instead of having an object statement that starts off
> oddly like:
Well, I'm so sure this is important. I think the intent is not to create
another IF langage, but to create a conduit where all languages can be
encoded similarly. I doubt anyone will actually _write_ a game in XML, but
many would use the XML version of a game to view it in some other fashion.
For myself, I would transport the XML to a database and build a visual tool
to edit it. Others may want to transport the XML to some other tool of their
design or choosing. Some may simply import it into an XML/DTD Editor and
feel comfortable with that.
I don't think one of the requirements should be readability. XML is not like
HTML where you're going to write it in a text editor. XML is strictly for
underlying transport.
Jarb
Graham Nelson
<URL:mailto:an...@azaal.dircon.co.uk> wrote:
> Obviously I based this around Inform, but I believe the above could
> be machine translated to Hugo and Jacl (I haven't looked at TADS enough
> to comment).
Easily it could. At the end of the day, though, the issue with
IF languages is not syntax -- syntax is easily reordered. The
issue is how the world model works and how it can be altered --
the thousands of intricately connected rules which model reality
within an interactive fiction. (What happens if a light comes on
inside a sealed glass cupboard on top of a very tall wardrobe,
from the perspective of a person in a cage. What happens if that
person types "throw shoe at light".)
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
David Cornelson
news:ant311520868M+4%@gnelson.demon.co.uk...
> In article <slrn86p891...@azaal.dircon.co.uk>, Andy Leighton
> <URL:mailto:an...@azaal.dircon.co.uk> wrote:
> > Obviously I based this around Inform, but I believe the above could
> > be machine translated to Hugo and Jacl (I haven't looked at TADS enough
> > to comment).
>
> Easily it could. At the end of the day, though, the issue with
> IF languages is not syntax -- syntax is easily reordered. The
But that's all we're talking about is syntax. We know that to work, the XML
would have to be neatly placed back into its working Inform text form. I
think we're interested in what we can do with the syntax once its been
ordered in a logical way. XML provides a method to do this.
Whether someone throws a shoe at a light or not is outside of the scope of
language translation. The Inform code can be written many different ways, as
well as TADS, and Hugo, but it shouldn't be that difficult to build XML
constructs around these blocks of code.
I guess I see your point though. Writing XML to conceptualize TADS _and_
Inform would be nearly impossible because when you get down to the nitty
gritty, they are two very disparate languages. Putting <FUNCTION></FUNCTION>
tags around codeblocks would help me write an editor, but it would not help
people write an XML game that could be compiled in TADS _and_ Inform.
But a caveat. We could add the ability to cross-develop using XML by
creating dual functions. When the conversion to Inform is done, only inform
functions are read and same for converting to TADS.
<FUNCTION name="XyzzySub" language="TADS"></FUNCTION>
<FUNCTION name="XyzzySub" language="Inform"></FUNCTION>
Someone versed in both languages could write a game that could be exported
to both compilers. This has far-reaching consequences.
Jarb
Happy Poster
"code-less" objects and manipulate their attributes and so on. In fact,
perhaps the XML editor can have 2 options -- walk around in sort of a quasi
3D world (simple vector graphics -- nothing Doom-like) or view it similarly
to Microsoft Visual XML Notepad (and other similar editors with collapse and
expand capability).
Then, when you are satisfied, you can export to Inform. Then, you can then
build code to intercept verb events with Before and After clauses to the
Object, as well as adding grammar rules and custom routines.
It's like an "Inform Jumpstart Kit", and, if written good enough, perhaps it
could be ported to make a "TADS Jumpstart Kit" or a "Hugo Jumpstart Kit".
Given that kind of scope, if that's how you feel and we get at least 2 other
people in agreement, we should begin writing the XML Schema. Heck, we can
even give it a name and submit it to http://www.oasis-open.org/ (aka
"Oasis"). We don't have to write any code at this point -- we just need an
agreement on a schema.
Happy
Kevin Forchione
>At the end of the day, though, the issue with
> IF languages is not syntax -- syntax is easily reordered. The
> the thousands of intricately connected rules which model reality
> within an interactive fiction.
As a developer of numerous library extensions for TADS I concur. With the
latest releases TADS has becomer very powerful, and yet the world model
itself has only altered a little with these releases, mainly through bug
fixes.
But as you begin to use something as complicated as the inform.t library
extension (or even more complicated, the still-in-development alt.t library)
and you come up against an interesting challenge: the coordination of the
multi-layered aspects of the library, from room display to general listing;
accessibility rules dealing with command parsing to accessibility rules
dealing with command execution.
Take the simplified Alice3.inf Tutorial, for instance. The TADS parser and
command execution process is quite capable of recreating the behaviours and
displays of this demonstration game; but the ADV.T library is not
sufficiently developed to handle the requirements, asis.
>(What happens if a light comes on
> inside a sealed glass cupboard on top of a very tall wardrobe,
> from the perspective of a person in a cage. What happens if that
> person types "throw shoe at light".)
These puzzles always lead to marvellous new developments. For TADS these
scenarios pose very interesting problems. Before the implementation of the
TADS sense.t and containment.t library extensions your choices were limited
to rooms or nestedrooms. For those unfamiliar with the TADS library neither
rooms or nestedrooms accomodate the concept of being openable.
What's more, the basic ADV.T library does not handle accessibility rules
correctly when you have an actor inside of a closed container because of the
top-level filter-down scoping mechanism. This is further complicated by the
fact that ADV.T's accessibility rules rely on class definitions, making them
brittle, instead of based on attributes. Thus the check for whether
visibility passes down into an object's contents is based on:
if (not isclass(obj, openable)
or (isclass(obj, openable) and obj.isopen)
or obj.contentsVisible)
Sense.t relies solely on the contentsVisible() check, which is defined for
the various types of containment. Using the "soft" attribute definition
allows us to tailor the accessibility within the object itself based on
requirements particular to the situation or object, as we shall see below.
Making the cage a separate room also has its own problems, mainly because
the ADV.T scoping mechanism is based on filtering down from a top-level
location, in general actions do not pass from one room to the next.
But I'd like to be more clear about the conditions. Our assumptions:
* the wardrobe and the cage are both located in a darkroom.
* the cage is closed
* the bars of the cage either will allow for the passage of the shoe or
will not; but the player is definitely unable to escape. (There are other
issues, such as whether the player can reach outside the cage and to what
extent, but I'll not address them for now.)
Using sense.t / containment.t, the <<throw>> action is checked during the
disambiguation stage as it passes from the player along the indirect- and
direct-object containment paths:
[ Me cage room wardrobe cupboard light ] with a lowest-common
containment of room.
[ Me shoe ] with a lowest-common containment of Me
The blocksPath() function checks the passToLocation() and passToContents()
methods for each object in the path, as well as each objects contentsXxxxx()
method for a given scope value. What this means is that in the case of
visibility-oriented actions, such as <<look at light>> each object's
passToLocation() and passToContents() methods are checked for scope_visible;
while each object is checked for contentsVisible().
The passToXxxx methods provide the author with a way to control the flow of
action through game-state code that might be unrelated to the object under
examination (i.e. is the player throwing a shoe or a cardboard box?).
The contentsXxxx methods, such as contentsReachable determine if the action
can cross the contents threshold (i.e. move between an object's location and
its contents) and is usually related to whether the object is "open" or not.
Modification of these attributes should simply check for specific actions
(i.e. <<throw>>)
Given this, if we make the cage a transparent openable and the room a
darkroom then the cage will be lit when the light comes on in the cupboard,
but we won't be able to throw objects outside the cage when it is closed. (I
have toyed with the idea of having an attribute that would cause rooms such
as the cage to remain in darkness, and only allow the player to see objects
within the room and cupboard, but the jury is still out on that one.)
In order to throw the shoe at the light we would first modify the
cage.contentsReachable() to return true for the action <<throw>>; otherwise
we would pass contentsReachable. This allows the <<throw>> action to pass
beyond the cage, even though it is closed, while keeping reachability intact
for other actions. At this point, however, at this point it is possible to
throw anything at all, a shoe, an iron anvil, etc.
>throw shoe at light
You'll have to open the sealed glass cupboard first.
Where is the shoe? Still in the player's inventory. Not very realistic in
most cases, the logical response would have been to have the shoe bounce off
or shatter the cupboard. But what has happened is that we've failed the
disambiguation process, validIo() for the light. This means that the parser
doesn't recognise the light as an indirect object; has produced a null set
for validIo(); has called light.isVisible(), which in Sense.t always
defaults to true; and has passed control to the failloc.cantReach()
method -- the location which blocked the <<throw>> action -- end of process.
We don't want the <<throw>> action to pass the cupboard, but we would like
<<throw>> actions to be redirected toward the cupboard when we can't reach
the objects inside them. Because Sense.t redirects the deepverb.cantReach()
to the location that failed the action, rather than the indirect object
itself, no matter what object we throw at in the cupboard we always end up
calling cupboard.cantReach().
By this time we know the actor, the verb, the preposition, and the failed
location (we have a disambiguation list containing [ smallLight ], but this
has not been disambiguated and there could be times where the list contains
ambiguous elements. We do not have a direct object -- it hasn't been
disambiguated yet.
Here we are faced with a dilemma, but a quirk of fate (or parser, rather)
provides a solution. The objwords() function does not return objwords(2) in
deepverb.cantReach(), but it does return the value for objwords(1). Thus at
the level of deepverb.cantReach() when we have an iolist we can still obtain
a direct object through the use of objwords(1), parserNounList(), and
parserResolveObjects(). All we have to do is parse the object words and then
execCommand() the redirection.
Now when we throw the shoe at the light the action is redirected via
cupboard.cantReach().
>throw shoe at light
With a thud the shoe bounces off the sealed glass cupboard, landing
harmlessly on the wardrobe.
This use of redirection is very useful in this case, and thanks to TADS new
built-in parser functions we can throw shoes at the smallLight all day.
But suppose we have something larger that won't pass through the bars, like
a beach ball?
We've already allowed the <<throw>> action to pass beyond the cage, but the
disambiguation process is the wrong place to do checks on the direct object
because we can't guarantee that the objects will be known. For example, we
know that anything we throw at the light will fail disambiguation because of
inaccessibility to the closed cupboard in validIo(). But the cupboard could
have been open, in which case the action would not have failed
disambiguation.
This means we've got to deal with two types of accessibility. One that deals
with actions and the states of containment; and one that deals with actions
and other game states, such as bulk or height or distance. And these
accessibility rules happen at different times in the command parsing and
execution cycle.
The second type of accessibility will be discussed in another posting.
--Kevin
========================
The code needed to generate the above examples. This code uses the inform.t
release 4.0, but could also have been done with sense.t release 2.2.4 and
containment.t 1.1.
/* use the HTML status line and prompts */
#define USE_HTML_STATUS
#define USE_HTML_PROMPT
#define USE_COMMON_SENSE
/* include the standard TADS libraries */
#include <adv.t>
#include <std.t>
#include <inform.t>
#pragma C+
modify story
starting_location = cage
;
greatHall: darkroom
sdesc = "Great Hall"
ldesc = "This is vast hall. "
;
cage: transparentItem
location = greatHall
noun = 'cage'
isenterable = true
isopen = nil
contentsReachable = {
if (command.verbPtr == throwVerb)
return true;
pass contentsReachable;
}
sdesc = "cage"
insideDesc = "The inside of the cage is cramped."
;
shoe: clothingItem
location = Me
noun = 'shoe'
isworn = true
bulk = 1
sdesc = "shoe"
;
wardrobe: fixeditem, surface
location = greatHall
noun = 'wardrobe'
sdesc = "wardrobe"
;
cupboard: fixeditem, transparentItem
location = wardrobe
noun = 'cupboard'
adjective = 'sealed' 'glass'
isopen = nil
sdesc = "sealed glass cupboard"
ioThrowAt(actor, dobj) =
{
"With a thud <<dobj.thedesc>> bounces off <<self.thedesc>>,
landing harmlessly on <<self.location.thedesc>>. ";
dobj.moveInto(self.location);
}
cantReach(actor) =
{
local dobj, ret;
if (command.verbPtr == throwVerb)
{
dobj = parseObjwords(1, self);
ret = execCommand(actor, command.verbPtr, dobj, command.prepPtr,
self);
}
else
pass cantReach;
}
;
/*
* Returns the resolved object corresponding to
* the objwords(n) and otherobj, if supplied. Returns
* nil if no objects were resolved.
*/
parseObjwords: function(n, otherobj)
{
local i, objList = [], resultList = [];
local tokenList = objwords(n);
local typeList = parserGetTokTypes(tokenList);
local startingIndex = 1;
local complainOnNoMatch = true;
local multi = nil;
local checkActor = nil;
local actor = command.actorPtr;
local verb = command.verbPtr;
local prep = command.prepPtr;
local usageType = PRO_RESOLVE_DOBJ;
local vlist, verprop;
local silent;
if (command.prepPtr == nil)
vlist = verbinfo(verb);
else
vlist = verbinfo(verb, prep);
if (vlist == nil) return resultList;
verprop = vlist[1];
objList = parseNounList(tokenList, typeList, startingIndex,
complainOnNoMatch, multi, checkActor);
if (objList == nil)
{
/* the noun phrase had a syntax error; give up */
return; // or whatever we want to do in case of error
}
if (length(objList) == 1)
{
/* valid noun phrase, but no matching objects */
"I don't see that here.";
return;
}
resultList = parserResolveObjects(actor, verb, prep, otherobj,
usageType, verprop,
tokenList, objList, silent);
if (car(resultList) == PRS_SUCCESS)
return car(cdr(resultList));
else
return nil;
}
smallLight: lightsource
location = cupboard
noun = 'light'
adjective = 'small'
sdesc = "small light"
islit = true
;
Sean T Barrett
>Where is the shoe? Still in the player's inventory. Not very realistic in
>most cases, the logical response would have been to have the shoe bounce off
>or shatter the cupboard. But what has happened is that we've failed the
>disambiguation process, validIo() for the light. This means that the parser
>doesn't recognise the light as an indirect object; has produced a null set
>for validIo(); has called light.isVisible(), which in Sense.t always
>defaults to true; and has passed control to the failloc.cantReach()
>method -- the location which blocked the <<throw>> action -- end of process.
>We do not have a direct object -- it hasn't been disambiguated yet.
>Here we are faced with a dilemma, but a quirk of fate (or parser, rather)
>provides a solution. The objwords() function does not return objwords(2) in
>deepverb.cantReach(), but it does return the value for objwords(1). Thus at
>the level of deepverb.cantReach() when we have an iolist we can still obtain
>a direct object through the use of objwords(1), parserNounList(), and
>parserResolveObjects(). All we have to do is parse the object words and then
>execCommand() the redirection.
>This use of redirection is very useful in this case, and thanks to TADS new
>built-in parser functions we can throw shoes at the smallLight all day.
I would think, though, that Graham's point was that this behavior
should be built in. Needing to reparse text when implementing something
"basic" means it's NOT built into the world model, right?
I think there's a significant flaw in the way most adventure world
models work. I'm not sure it's an IMPORTANT flaw; for the sake of
getting stuff done, it may well be the right compromise (or, rather,
TADS' approach may be the right compromise).
Ideally, what we want to have happen is something like this:
- player inputs text
- parser figures out what player meant
- parser maps noun phrases onto objects in the world
- parser disambiguates object choices based on player's
knowledge of the world
- parser maps the player's text into an "action"
- world model carries out the action
All world models that I know of collapse the modelling of the
player's knowledge of the world with the actual behavior of
the world. If there's a transparent container between the
player and a button, the player is prevented from throwing
her shoe at the button from within the cage--which is helpful,
since the player won't lose the shoe. If there's a forcefield
which the player doesn't know about and doesn't see, however,
the exact same check will also stop the player from doing it;
(Or vice versa, depending on how you do it.) My preference
for the "right" thing is for these two cases to vary, but
the ONLY difference in world modelling terms betwee them
is that the player knows about (can see) one and not the other.
Also, automatic disambiguation based on the *world action*
instead of player knowledge COULD be bad; the fact that an
action does nothing does not always make it the wrong action:
> w
Elevator Lobby
> push button
You push the elevator call button, but nothing happens. After all,
this elevator has been dysfunctional for years. You ordered it
sealed off yourself.
[...]
> i
You're carrying the nuke remote control.
> push button
You push the big red button on the remote control.
Somewhere, in hardened missile silos, the first strike
begins. Come, armageddon, come.
*** You have lost ***
[...]
> w
Elevator Lobby
> push button
Which button do you mean, the elevator call button or the big red button
on the remote control?
As I understand it, a natural implementation of the above scenario
in TADS will result not in the disambiguating reply, but in the
second result instead. Of course it's perfectly possible to implement
this correctly in TADS (or Inform, or anything), but if the author
never even imagined the button being near any other buttons...
Somewhere I have something about this in my notes, ah, here it is:
=-=-=
One of the things I'd like is a library/parser combination
which doesn't conflate the following notions:
0. whether the player is in proximity to an object
1. whether the player can see an object
2. whether the player can touch an object
3. whether the parser should understand a given phrase
as referring to a particular object in a given context
4. whether a given ambiguous noun phrase might refer
to a given object in a given context
5. whether a given verb has a simulation effect on a given object
6. whether a given object can interact with the player
Some examples of this conflation:
The omnipresent use of 'scope' in the Inform library; for
example, the "react_before"-in-the-dark "bug" basically
conflates 1 and 6--more accurately, makes 6 depend on the
*parser*.
The ver* functions in TADS which are overloaded to serve
both 4 & 5, as I understand it.
Looking at the Infocom bug list, it seems their handling
of 'again' and 'it' were plagued by this problem--they
relied on the *parsing* to know that a referred-to-object
was local, and thus 'it' allowed non-local references,
allowing confusion between 0 and 6.
Of course, in practice, the reason we allow these to be conflated
is because it would be really annoying to have to specify each
of these properties independently. Unfortunately, as soon as
someone extends the simulation in unexpected ways--e.g. allowing
a video camera that can view another room, and thus allow, say,
'look at' at a distance, they are forced to use hacks to resolve
which things can work and which cannot.
The best implementations of this sort of scheme I have seen have
been systems in which NPCs issued commands identically to the player,
EXCEPT that they were allowed to bypass the parser, so the verb
implementations were simply paranoid and didn't rely on the parser
to have implied ANY constraints (I've seen this on muds, specifically).
The worst implementations of this sort (especially found in Infocom
games) lead to games which are really horrible about checking basic
positional properties in their verbs, leading to bizarre effects,
e.g. when performing actions from within enterable objects.
My desire here is not to improve the state of the art of simulation
in IF, but rather to produce a better experience for the player.
The parser's job is to guess as best as it can the meaning of the
player, and map these onto simulated actions. The parser should
model the *player's knowledge of the world*, not the *world*.
=-=-=
Sean B
skipro...@email.com
"Happy Poster" <ha...@poster.com> wrote:
> if (player has dog) {
Erm, perhaps you mean (dog in player)?
Sent via Deja.com http://www.deja.com/
Before you buy.
skipro...@email.com
Suzanne Britton
buz...@world.std.com (Sean T Barrett) wrote:
>Also, automatic disambiguation based on the *world action*
>instead of player knowledge COULD be bad.
Right on (this, and other points you made as well). This is something
that's bugged me about TADS verification methods for a while: the fact
that they lump two different functions into one:
- Determining what works
- Choosing defaults
An example that comes to mind is a puzzle in a competition game where you
must figure out to cut glass with a diamond ring. But if you just type
"cut glass", the parser will do this--
[with the diamond ring]
Blah blah...
--because it chooses a default based on game knowledge rather than player
knowledge. In this respect, I think Inform's chooseObjects is better and more
flexible. But I've put this idea in Mike Robert's head when we were chatting
about TADS 3, so TADS 3 may well have a better solution than both of them :-)
Suzanne
--
tr...@igs.net http://www.igs.net/~tril/
Author of "Worlds Apart" http://www.igs.net/~tril/worlds/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- "You see, if I can't turn it off in another 5 seconds, the car will
transform into an indestructable robot that will destroy the entire world."
- "You really like this car, eh?" -- Radio Free Vestibule
Happy Poster
rather than how Inform would like me to have it.
Happy
Mike Arnautov
[Lots of interesting stuff snipped]
>The best implementations of this sort of scheme I have seen have
>been systems in which NPCs issued commands identically to the player,
>EXCEPT that they were allowed to bypass the parser, so the verb
>implementations were simply paranoid and didn't rely on the parser
>to have implied ANY constraints (I've seen this on muds, specifically).
Ah. I was reading your post and coming to the conclusion that I'd better
air my recent musings on the subject of parsing. From the above, it
would seem that you are at least inclined to think in the same
direction.
An apparently stupid question... Should there be a parser as such? Are
we right to expect to be able to hand the player's input to something
called The Parser and then process the result? It seems to me that the
answer might be "no" -- for all the reasons you have touched upon, plus
some others. Parsing of human language is far too context dependent and
the interplay between (a) the player's knowledge, (b) the universal laws
of "physics", (c) the specific objective context and (d) the subtleties
of usage of specific verbs/nouns -- this interplay is so complex that in
order to handle it within The Parser, this mighty entity would
effectively have to lose its boundaries.
So what's the alternative? Well, if parsing is such a distributed
activity, shouldn't it be implemented as a distributed activity?
Shouldn't verbs and objects have their own mini-parsers (at least
potentially), possibly supplied by the IF author, to cater for the
specifics of his universe? E.g. shouldn't disambiguation happen by *all*
potential targets invoking their "mini-parsers" to decide whether to
vote themselves in or out -- with The Parser acting only as (a) the
arbiter in case of disagreements and (b) the supplier of default parsing
where specific parsers are absent?
All of this may be a complete nonsense, of course, but my gut feeling is
that distributed parsing is something that would be useful at least to
play with.
--
Mike Arnautov | From the heart
http://www.mipmip.demon.co.uk/mipmip.html | of the sweet peony,
mailto:m...@mipmip.demon.co-antispam-uk | a drunken bee.
Replace -antispam- with a single dot. | Basho
Mike Arnautov
>An example that comes to mind is a puzzle in a competition game where you
>must figure out to cut glass with a diamond ring. But if you just type
>"cut glass", the parser will do this--
>
>[with the diamond ring]
>Blah blah...
>
>--because it chooses a default based on game knowledge rather than player
>knowledge.
Ouch! :-) But don't throw the baby out with the bath water. My personal
bugbear is the following sequence:
? unlock door
What do you want to unlock door with?
[A key, you idiot -- would I be unlocking it with my lamp???]
? unlock door with key
Which key do you mean? The silver one or the gold one or the iron one
or...
[Can't you try all them keys for me and see whether one fits?!]
? unlock door with iron key
It doesn't fit.
[Sigh...]
? unlock door with sliver [sic.] key
I see no sliver key here!
[Yeah... I can't type!]
? unlock door with silver key
You unlock the door.
[Well, hooRAY!]
As opposed to
? Unlock door
You try various keys in your possession and are delighted to find that
the silver one does the trick. The door is now unlocked.
Intelligent defaulting is a great boon! As long as it does not become a
spoiler, as in your example.
Kevin Forchione
news:84me0o$qig$1...@news.igs.net...
> [WARNING: competition game puzzle spoiler follows]
>
> buz...@world.std.com (Sean T Barrett) wrote:
>
> >Also, automatic disambiguation based on the *world action*
> >instead of player knowledge COULD be bad.
Unfortunately Sean's posting does not seem to be on my newsreader. From the
snippets I gather it has several very good points.
Most *probably* automatic disambiguation based on the *world action* instead
of player knowledge is bad.
One significant drawback to the current mechanism is that of having to
handle cases where an object has obviously failed the rules of
accessibility, but *is* accessible to the actor for some actions, such as
attempting to take an object that is within a sealed transparent container.
In these situations it would probably be better to continue with the
disambiguation process, passing on any relevant information to a world model
process.
For instance:
>throw shoe at light
fails the disambiguation test for accessing an object that is in a
transparent sealed container in both ADV.T and sense.t mechanisms. But it is
probably more correct to say that both shoe and light are in the actor's
scope (i.e. the actor has access to both of the objects through *some* (at
least one) accessibility rule, such as visibility).
We would continue the disambiguation process in such a case, and then pass
onto the world model processing. The process could then determine if the
*action* is valid within the model world for these objects. (It might also
determine if any implicit actions are required.) Thus any desirable
redirections can be made based on game objects, not player input.
Finally we would pass on to the actual command execution. Ideally command
execution would allow for a status code return from the action method, such
as true, nil, exitobj, or an author-defined value.
> Right on (this, and other points you made as well). This is something
> that's bugged me about TADS verification methods for a while: the fact
> that they lump two different functions into one:
>
> - Determining what works
> - Choosing defaults
>
> An example that comes to mind is a puzzle in a competition game where you
> must figure out to cut glass with a diamond ring. But if you just type
> "cut glass", the parser will do this--
>
> [with the diamond ring]
> Blah blah...
>
> --because it chooses a default based on game knowledge rather than player
> knowledge. In this respect, I think Inform's chooseObjects is better and
more
> flexible. But I've put this idea in Mike Robert's head when we were
chatting
> about TADS 3, so TADS 3 may well have a better solution than both of them
:-)
It's great when puzzles of these sort generate such fruitful discussions on
the parser and world model. I agree with you Suzanne on each of these
issues. As an example, an examination of ADV.T reveals that both verGrab()
and cantReach() have code in place to handle an attempt to remove things
from a closed transparent container.
The line between the role of the parser and that of the world model need to
be delineated more clearly. I'm sure T3 is going to involve a review of the
two.
I've especially enjoyed this discussion. Doubtless there are ways to improve
the performance of the T2 model.
For example, it should be possible to modify the mechanism of sense.t to
further differentiate object disambiguation from the model world. Sense.t
already provides a proximity function that indicates whether a target is
accessible to a vantage by *any* accessibility rule. A modification of the
validDo() and validIo() methods would then fail only objects to which the
actor has no access whatsoever.
It would then be the job of another stage (probably at preCommand or
verbAction) to detemine if the *action* is valid for the objects within the
context of the model world. At this stage the handling would be more
consistent. I'm going to look into this sort of modification to sense.t.
But the verification and default object methods still remain a thorny issue
, as you point out. For T3 it's going to be exciting times, indeed!
--Kevin
Kevin Forchione
news:84me0o$qig$1...@news.igs.net...
> [WARNING: competition game puzzle spoiler follows]
>
> buz...@world.std.com (Sean T Barrett) wrote:
>
> >Also, automatic disambiguation based on the *world action*
> >instead of player knowledge COULD be bad.
I foud Sean's posting on Deja.com (Apparently MSN isn't capable of
translating the word "conflate"). I find his final statement very
interesting.
>>The parser should model the *player's knowledge of the world*, not the
>>*world*.
If memory serves me right, the validXoList() was added to the deepverb
structure in order to speed up the parser's processing. Consequently it was
most convenient to limit this list using visibility rules. The validXo()
method is much older, and uses reachability rules (except in the case of
inspectVerb, which uses visibility rules.) It is mainly the tradeoff for
parsing speed that has produced the merging of TADS disambiguation and model
world processes. But the rules of the model world are *not* part of the
parser per se.
In fact it is perfectly legitimate to divorce the model world rules from the
validXoList and validXo methods; pushing the determination of these rules
into the command execution phase. Sense.t does this already to some extent
by returning nil for validXoList(). Returning true from validXo() also will
result in the parser's original parsed noun list being used by the silent
verification calls.
With the past couple releases of TADS we have the disambigXobj() methods,
which are being used by extensions like Chatter.t to handle TOPIC object
disambiguation, are the closest equivalent to inform's ChooseObjects().
Putting the rules of the model world into a function called by the
verbAction() method has so far produced satisfactory results for the
sample2.t source that comes with sense.t. In this case I have, of course,
adapted the functions and methods used by the validXo() methods, reusing the
deepverb.cantReach() method for cases that fail the accessibility rules.
Unless I am much mistaken, this method will never be called by the parser
because the list produced by validXo() will never be empty.
Thus when accessibility fails in the case of our <<throw shoe at light>> all
the objects of the player command are known. Control is passed to
verb.cantReach(). The advantage here is that verbs such as throwVerb can
redirect the action, while verbs such as takeVerb do not require
redirection. For redirection we use execCommand(), which processes the
command without requiring any disambiguation.
The tradeoff, again, is parsing time. The only way to speed up parsing time
is by using some mechanism to limit the number of objects in the selection
lists. But world model rules do not have to be a part of the mechanism.
--Kevin
Philip Goetz
news:84eutr$b8o$1...@bgtnsc02.worldnet.att.net...
> "Ross Presser" <rpre...@NOSPAMimtek.com.invalid> wrote in message
> news:8EAB8BB1...@199.45.45.11...
> > alt.distingui...@aol.comRemove
> > (BrenBarn).wrote.posted.offered:
> >
>
> that I wrote into an example XML document.
...
> ------------</COMMENT>
> <WS></WS>
> <CONSTANT name="Story" type="string">SpeedIF6 - A Top Hat for
> Eddie</CONSTANT>
> <CONSTANT name="Debug" type="function"></CONSTANT>
> <WS></WS>
> <CONSTANT name="Headline" type="string"><NEWLINE></NEWLINE>SpeedIF
> 6<NEWLINE></NEWLINE>by David A.
> Cornelson<NEWLINE></NEWLINE><NEWLINE></NEWLINE></CONSTANT>
I think this example proves how truly horrible it would be to write IF in
XML.
Phil Goetz
David Cornelson
news:Il3c4.22795$W2.2...@iad-read.news.verio.net...
> David Cornelson <dcorn...@placet.com> wrote in message
> news:84eutr$b8o$1...@bgtnsc02.worldnet.att.net...
> > "Ross Presser" <rpre...@NOSPAMimtek.com.invalid> wrote in message
> > news:8EAB8BB1...@199.45.45.11...
> > > alt.distingui...@aol.comRemove
> > > (BrenBarn).wrote.posted.offered:
> > >
> >
> > Just for kicks I translated a SpeedIF game (minus the bulk of my
objects)
> > that I wrote into an example XML document.
>
> XML.
That was someone elses thought. I give no value to writing XML directly
either. The only use I see is that of translation from an Inform text file
to XML to ??? and back to XML to an Inform text file. The ??? can be pretty
much any 'organized' view of the code that people want. As I stated, I would
import the XML (easily) into a relational database (Access) and build (in
Visual Basic) a Win32 tool that would allow people to code their games.
There are still some sticky technical issues, like syntax highlighting and
checking, something I would want very much to add to the tool I create.
These things would require a probably major reworking of the compiler
routines to spit out messages on a small piece of code, like ("Missing
semicolon", 27) and I would use this to display the error and highlight line
27.
The text area I used would likely need to be some sort of sophisticated RTF
text box that allowed coloring and such. It might even be necessary to make
a text box of my own that handles events appropriately and has some
extensibility for people.
Anyway, I digress. I don't see anyone writing XML IF either...
Jarb
Kevin Forchione
> Anyway, I digress. I don't see anyone writing XML IF either...
So, if I'm understanding correctly, you want to use XML as an intermediate
format, to translate between Inform, Hugo, and TADS, in order to save time
coding room object definitions?
At the end of the day the Inform -> XML -> TADS conversion will give you
nothing but a source code of 60 or so room definitions. Despite all the talk
about how similar TADS and Inform are, no one will argue that the mechanics
behind how they do things is quite disimilar.
So the return on the time spent to develop this conversion process seems
minimal to me, unless you plan on doing a *lot* of TADS to Inform
conversions of room definitions.
Wouldn't you be better off using a few macros in a text editor?
--Kevin
David Cornelson
news:OrugQxpV$GA.229@cpmsnbbsa04...
> "David Cornelson" <dcorn...@placet.com> wrote in message
> news:84rc56$m0n$1...@bgtnsc03.worldnet.att.net...
> > Anyway, I digress. I don't see anyone writing XML IF either...
>
> So, if I'm understanding correctly, you want to use XML as an intermediate
> format, to translate between Inform, Hugo, and TADS, in order to save time
> coding room object definitions?
>
Thought about this after Graham's post. No. I see no practical use of trying
to translate complex code blocks in any language. This means that 'if' and
'switch' and 'for' and basically anything inside of square brackets would be
left alone and placed inside of <CODE></CODE> tags.
My focus is Inform and only Inform, for now. And building objects is not my
only design. I would want to build a visual tool that could handle any level
of compleities with grace.
The nice part is that if I ever do get a working visual tool for the Inform
language, and using XML, I could very likely create TADS and Hugo versions
with less than wholesale changes. In the end, you might have a common visual
tool for all three languages.
I'm attempting to build a prototype of my idea. We'll see where it goes.
Jarb