[ALL] Choosing a Tool
Soon-Min Yee
'killer reason' to go with one tool or another? For example one thing
I could think of is that you want to be able to have your game played
on as many platforms as possible. Or is that right? For me I would
only think to worry too much about Linux, Mac, and PC. (Do people
*really* do a lot of playing of these games on Palm pilots or things
like Pocket PC? And I notice a lot of Z-Machine emulators for things
like Spectrum, Oric, Newton, GEM, Apple II, etc. But are enough people
really using these platforms that it makes any difference whatsoever?
I have to assume some people are, otherwise why make the emulator?)
What is the common denominator that people tend to develop for and so
choose a tool for?
If the ability to have the game played on various platforms is not the
main decision point, then what is for most people? Is it the
extensions available? The power of the language? Is it for the ability
of the interpreters to degrade gracefully? (For example I know
Glulx/Glk has only hints that things should work a certain way, but no
requirement that they do so. So I am not sure how graceful that is.) I
am also wondering if this push for graphics and sound has caused more
confusion in the choice of a tool since it seems that is a big point
for some people, but also harder to implement cross-platform.
Graham Holden
>In choosing a tool to develop with, has anyone come up with the
>'killer reason' to go with one tool or another? For example one thing
>I could think of is that you want to be able to have your game played
>on as many platforms as possible. Or is that right? For me I would
>only think to worry too much about Linux, Mac, and PC. (Do people
>*really* do a lot of playing of these games on Palm pilots or things
>like Pocket PC?
I can only speak personally, but I play IF (and do most of my non-work
computing) almost exclusively on my Psion 5mx (or sometimes a NetBook)...
I have a longish commute on the train to and from work, and the Psion is
ideal for this since it is more than fast enough, has a good keyboard and
is instant on/off.
I can play Z-code games, TADS-2 (non-HTML) and (as I've just found) Hugo
games. Anything other than these would need to squeeze into the end of
lunch times at work...
> And I notice a lot of Z-Machine emulators for things
>like Spectrum, Oric, Newton, GEM, Apple II, etc. But are enough people
>really using these platforms that it makes any difference whatsoever?
>I have to assume some people are, otherwise why make the emulator?)
At the risk of being shot down in flames, I suspect that most of these
platforms are not in daily use; some of them may have been used "for real",
but I suspect in many cases Z-machines for them have been developed for the
same reason people climb Everest... because it's there.
>
>What is the common denominator that people tend to develop for and so
>choose a tool for?
I suspect the reason *most* authors (but by no means all) choose one of
Inform or Tads over any of the other IF-specific language IS because their
works can then (potentially) reach a wide audience (Plus you're likely to
get the most offers/ability to help if you stick to one of the "mainstream"
languages).
Why they would choose one in particular is a different issue. Personally,
should I ever actually get around to writing a game, I would more than
likely choose Inform, because (a) it's the one I know best and (b) it's the
one that "plays best" on my Psion. The superficial knowledge I have of
Tads-3 makes it tempting from a technical point of view, but I'd be unable
to use my Psion other than as a portable editor, so its chances are low at
the moment [but then the chances of me actually writing ANYTHING are low!)
>
>If the ability to have the game played on various platforms is not the
>main decision point, then what is for most people? Is it the
>extensions available? The power of the language? Is it for the ability
>of the interpreters to degrade gracefully? (For example I know
>Glulx/Glk has only hints that things should work a certain way, but no
>requirement that they do so. So I am not sure how graceful that is.) I
>am also wondering if this push for graphics and sound has caused more
>confusion in the choice of a tool since it seems that is a big point
>for some people, but also harder to implement cross-platform.
Regards,
Graham Holden (g-holden AT dircon DOT co DOT uk)
--
There are 10 types of people in the world;
those that understand binary and those that don't.
Kevin Venzke
"Soon-Min Yee" <SoonM...@yahoo.com> wrote in message
news:62cba875.04100...@posting.google.com...
> What is the common denominator that people tend to develop for and so
> choose a tool for?
I would want to reach the most people, and so use TADS 2 or Inform.
But I wouldn't rule out TADS 3 or Hugo.
Inform code looks very strange to me, whereas TADS code looks like
stuff I'm familiar with from elsewhere. Also, I'm vaguely aware that
Inform games have certain limitations (due to the Z-Machine), and that
is at least a little worrying.
And now that I can make TADS do what I want, it would be painful
to start over with something else.
However, I get the impression for some reason that novices' Inform
games look better than novices' TADS 2 games. Either that's something
to do with the libraries, or maybe TADS 2 novices just aren't as skilled.
(Or maybe TADS 2 is easier to start working with...?)
No offense taken by anyone, I hope.
Kevin Venzke
Eric Eve
> 'killer reason' to go with one tool or another?
> What is the common denominator that people tend to develop for and
> so
> choose a tool for?
>
> If the ability to have the game played on various platforms is not
> the
> main decision point, then what is for most people? Is it the
> extensions available? The power of the language? Is it for the
> ability
> of the interpreters to degrade gracefully?
Well, if I was asked to guess which factors weighed in people's
choices, I'd say it might be a combination of:
(a) The tool's track record; e.g. the fact that a lot of good IF
has been written in Inform and TADS is an incentive to plump for one
of those languages.
(b) Familiarity (i.e. I suspect that at least some people will
tend to stick with the first IF language they stumble across,
provided they're reasonably happy with it, since mastering any IF
language represents a non-trivial investment of time and effort)
(c) The support available in terms of documentation, tutorials
and existing user base.
(d) The ability to have the game played at least on a reasonable
range of platforms
(e) The power of the language and available extensions.
(f) Perceived ease-of-use.
(g) The tastes and backgrounds of different users (e.g. someone
who sees themselves primarily enjoying IF as a form of writing may
be looking for rather different things from someone who primarily
enjoys programming as sees IF as a fun thing to program).
(h) For some people the multimedia capabilities of the language
may be an important issue; for others this may not matter at all.
What I don't know is how many people actually try out two or more
different IF languages and then settle on the one they like best
(which might be implied by the word 'choose'). I started out with
Inform (having come across a series of tutorials on it in PC Plus),
then, out of curiosity, looked at TADS 2 and found it to have
several nice things that Inform didn't (as well as lacking, or at
least seeming to lack, some nice things that Inform had), and then,
again out of curiosity, took a look at TADS 3, and then stuck with
it, since it had everything I liked in Inform and TADS 2 and quite a
lot more besides; so, I suppose for me, the power of the language
was a strong consideration. If I had to nominate one killer feature
that attracts me to TADS 3, I'd probably say it was the power of the
conversation system, which allows you to create complex interactions
with NPC with a minimum of programming effort; but the
sophistication of the world model would come a close second, and the
feeling that I'm most unlikely to run up any limitations of the
system a close third.
-- Eric
Keyton Weissinger
playing with Inform (building my first game) and hope to implement the
same thing in TADS3 next. Right now I'm leaning towards Inform for one
simple reason: the documentation available for Inform is amazing.
Eric's TADS3 beginner's document is very nice (I've not really dived in
yet, but have given it a quick perusal), but Roger Firth and Sonja
Kesserich's Beginner's Guide for Inform has the benefit of having been
around for longer (and started at least by three sets of hands -- so
there is more of it).
Roger's site is frankly AMAZING as well. There may very well be this
support community present for TADS3, but it's not as obviously present
(though I've not yet looked exhaustively, I must admit).
Finally, I would look to the DM4. While a bit dry and dense, it really
is EVERYTHING about Inform. You may not love it, but you know where it
all is, as it were.
Now, I will be my own devil's advocate: I like the idea of better NPC
interractions (I'd heard that before Eric's post). I already know that
doing this in Inform will be non-trivial. We'll see.
In the mean time, I will finish out my first Inform game and then take
a look at TADS3 and report back....
Keyton
Jeff Nyman
> 'killer reason' to go with one tool or another? For example one thing
> I could think of is that you want to be able to have your game played
> on as many platforms as possible. Or is that right? For me I would
> only think to worry too much about Linux, Mac, and PC.
For myself, and I am a new author (or trying to be), my main focus has to
be, out of necessity, what you describe as the "big three": PC, Mac, Linux.
But, that said, as one poster already said, if you choose Inform, you may
get more porting possibilities (like Psion). If you are not concerned with a
lot of "extras" - like graphics and sounds - you can probably choose any of
the major IF systems, from what I have seen, and cover not only your base
three platforms but quite a few others as well (BeOS, Amiga, etc). But I
think it can be taken too far. For example, I know there was discussion
about being able to run Inform games on Commodore 64 emulators, something I
doubt is possible with TADS 2 or Hugo right now. I will be the first to
admit that it is kind of nifty to see your game playing on a Commodore 64
interface but, on the other hand, I am not sure that a primary goal for me
is making a Commodore 64-capable version.
> What is the common denominator that people tend to develop for and so
> choose a tool for?
I am actually still deciding on what tool to use. I have tried starting a
new game in Inform, TADS 2 and Hugo. Basically I took a set of features for
the start of my game that I wanted to make sure the tools could handle and
tried to code up the same feature set in each tool. The result: I like all
of the tools, for different reasons. I am still not quite certain which one
I will settle on. I like what TADS 3 seems to be in the process of becoming
right now but I worry about the size of the files it seems to produce in
terms of how that might speak to portability. That said, I can offer no
pronouncements one way or the other on that since I have not really
investigated it fully. I like TADS 2 quite a bit for its general language
structure and its ease of use regarding markup for formatting.
> If the ability to have the game played on various platforms is not the
> main decision point, then what is for most people? Is it the
> extensions available? The power of the language? Is it for the ability
> of the interpreters to degrade gracefully?
For me, I want to know how well the language and system handles (or has the
ability to handle) things like NPC interaction. I fancy myself trying to
write a game that will at least utilize some of these abilities. I like the
ability to have things like changing to first person or second person games.
Right now Hugo does this very easily; Inform does have an extension set
(ORLibrary) that allows this, but that is the only ability of that of which
I am aware. TADS 2 seems (at first glance) fairly easy to modify to handle
this. Will I use that ability in any language? I have no idea, but I like
knowing it is possible.
I am not too concerned if it is "hard" to implement these features, but then
if it is I would hope there are extensions available or good documentation.
One thing that is interesting is alternate libraries. TADS 2 has a few (like
Pianosa, WorldClass, Alt, wadv) and Inform has one major one that I am aware
of (Platypus). I am not sure if this indicates anything in particular about
how easy or not it is to create alternate libraries. It might also mean that
the TADS 2 was lacking enough to necessitate four libraries while Inform's
library was considered not as much in need of alternate libraries. Or
perhaps it is just easier to do this in TADS 2 than in Inform. Why it is the
case is less of concern to me than knowing that options like this are
available.
I also like the idea of a Java applet being able to play the games. I think
that is a handy feature that can potentially offset some of the concerns
over porting to some systems. Again, it is more an issue of just knowing
that options like this are available.
> am also wondering if this push for graphics and sound has caused more
> confusion in the choice of a tool since it seems that is a big point
> for some people, but also harder to implement cross-platform.
Honestly, that may be true in some cases. All I can speak for is myself. I
started looking at doing graphics and sounds but after I got over the "neat"
factor, I started to realize that about the only thing I might want a
graphic for would be a title screen and there are very few times I would
ever want sounds anyway. And with that, as long as I can build in
conditional logic to handle interpreters that do not support that ability,
then I am okay with that. My hope is that my story is engaging enough and
the puzzles challenging enough. If that is the case, all the other frills
that a tool might offer are hardly of concern. But that said, I need the
tool to support my view of "engaging enough" and "challenging enough".
Like I said, I am still sort of on this quest myself. The problem is that it
is easy to get into a sort of "analysis paralysis" looking at each system
because, in the end, many (like TADS 2, TADS 3, Inform, Hugo) all offer
similar features. Sometimes having more choices available to you can seem
like a curse, of sorts. I have found the best thing for me is to start
coding my game in a few top contender languages of choice and then see where
I run into problems. Then I see what options are available for me to cope
with those problems. Admittedly, this is a longer process than most people
would probably prefer but it is helping me focus on key issues a little more
and helping me realize that some issues are not as "key" as I thought.
- Jeff
Greg Boettcher
If you haven't already done this, I suggest playing a bunch of games
written in Inform and TADS and whatever languages you're considering.
See if you prefer the look/feel/gameplay of Inform games over TADS
games, or vice versa. That was the biggest deciding factor for me.
See also
http://www.firthworks.com/roger/cloak/
and
http://www.drizzle.com/~dans/if/tads-vs-inform.html
Greg
Soon-Min Yee
> My hope is that my story is engaging enough and
> the puzzles challenging enough. If that is the case, all the other frills
> that a tool might offer are hardly of concern. But that said, I need the
> tool to support my view of "engaging enough" and "challenging enough".
I like how you say this. The story more important overall then any
features of the tool as long as the tool supports how you want to
build your story. I guess that makes sense. But then that means you
have to figure out how each language will allow you to build your
story. So how did you go about doing this in a way that isn't a total
waste of time and effort? Did you just learn enough of Inform and then
enough of TADS 2 and then try to write the same thing in both? What if
a later part of your game requires something and then you kick
yourself because you chose the wrong tool for the job? Unless you code
the game in both languages.
I think part of it is too that you end up liking a certain tool but
you realize other tool might do the job better so you almost have this
resistance to get to mired in one tool at the expense of the one that
might better handle the job.
Adrien Beau
>
> Also, I'm vaguely aware that Inform games have certain
> limitations (due to the Z-Machine), and that is at least a
> little worrying.
You can compile Inform to Glulx instead of Z-Code, which gets rid
of the limitations.
--
spam....@free.fr
You have my name and my hostname: you can mail me.
(Put a period between my first and last names).
Susan Davis
> things like Pocket PC?
Yes. That's where I do most of my game play: under Frotz on my Zaurus
PDA. (And before that, on my Palm Pilot.)
--
Susan Davis <s...@sue.net>
Jeff Nyman
news:<wHE8d.418024$8_6.347809@attbi_s04>...
>
> features of the tool as long as the tool supports how you want to
> build your story. I guess that makes sense. But then that means you
> have to figure out how each language will allow you to build your
> story. So how did you go about doing this in a way that isn't a total
> waste of time and effort?
I am not sure that it wastes time and effort but I guess that depends on how
quickly you are hoping to get something out the door, so to speak. My goal
was not to code the whole game in all languages; rather I had already
narrowed it down to a few languages and then tried a few things that I knew
I would want to do in my full game and see how I am able to code that in the
tools of choice. I also had to make some considerations that were beyond the
language coding, such as what you started with: what platforms do I want to
support? But ultimately I came to realize that if people choose to play
*only* on a platform that my language of choice does not support, there is
not much I can do about that. I figure I am pretty safe with the PC, Mac,
and Linux crowd. You have to realize that even though people may play on one
platform, it does not mean they would never play on another one,
particularly in the case of things like palm pilots or PocketPC. If that is
the *only* platform a player will use they are the ones doing the limiting,
not me just because I picked a tool that allows me tell an engaging and
challenging story.
> Did you just learn enough of Inform and then
> enough of TADS 2 and then try to write the same thing in both? What if
> a later part of your game requires something and then you kick
> yourself because you chose the wrong tool for the job? Unless you code
> the game in both languages.
As to the first question, yes. I learned enough about both languages to at
least let me get started. As to the second question, I am not sure. As I
said, most of the tools I settled in seem to have the capabilities to do
what I would want. Whether *I* have the capablities to put the language
through its paces to get me what I want is a different issue.
> I think part of it is too that you end up liking a certain tool but
> you realize other tool might do the job better so you almost have this
> resistance to get to mired in one tool at the expense of the one that
> might better handle the job.
That could be. Or you find that you can do certain things in a given
language and you are not even sure how to begin doing this in another
language. For example, I had written a game in Inform for my Quality
Assurance Web site (the game being "The Quest for Test") and in that game I
borrowed (with credit) the puzzles from Inform's "The Magic Toyshop". I had
really wanted to convert that game to TADS 2 but, to be honest, I have no
idea even how to begin, nor do I know if it is possible given how the game
handles things like arrays and ASCII-based formatting for things like a
tic-tac-toe board. So impetus might keep me in Inform for my next game even
though I might like how TADS 2 does things. But I am trying not to allow
that to sway me. Likewise, I finally finished making an Inform extension
(betahtml.h) work with Glulx. I would have no idea how to craft something
like even the original tool in TADS 2 or Hugo and that, again, might provide
impetus for me to stay with Inform. As I had indicated, I am still not sure
what I am going to stick with in terms of tools. Or I may not force myself
into the dichotomy and accept that one of my games is in Inform and the
other will be in TADS 2.
- Jeff
Kevin Venzke
"Adrien Beau" <spam....@free.fr> wrote in message
news:1966097.i...@maya.enadir.net...
> You can compile Inform to Glulx instead of Z-Code, which gets rid
> of the limitations.
>
That's nice to know. Incidentally...
I did a search on "glulx etymology" and wound up in the DM4 index
(due to "etymology of 'room'"). Not helpful there.
Going to eblong.com/zarf/glulx/ I see:
"Before Anybody Asks...
MIME type "application/x-glulx". On the Mac, file type "UlxG", and the
standard Glulxe interpreter uses creator code "gUlx". "
I don't understand what this means, but is it the origin of the name?
I don't recall it being an Enchanter spell or anything...
Kevin Venzke
samwyse
> What is the common denominator that people tend to develop for and so
> choose a tool for?
Well, I can't speak for "common", but here are some of my reasons.
One thing about Inform is that by default it compiles to the Z-machine.
The passing of Infocom was probably the best thing that could have
happened to the Z-machine architecture, because the Z-machine has become
like Latin: pretty darn stable. Any interpreter has to run the Infocom
games because they are the "canon" of I-F, otherwise what's the point of
writing it? And everyone pretty much has to have a Z-macine interpreter
so they can play the "canon". Thus, any game compiled for the Z-machine
is pretty much guaranteed to be playable by almost anyone, and to still
be playable centuries from now.
On the other hand, TADS is on its third architectural iteration and
there are enough differences that you really need three interpreters to
play the games. Yes, the VM's instruction set gets "better" with each
iteration, but like Java it is strongly CISC (complex instruction set
computer) whereas the Z-machine is more RISC (reduced instruction set
computer), which makes it a bit easier to implement an interpreter.
Yeah, people sometimes write 'terps for various machines just for
bragging rights, but a Z-machine interpreter was available for my Palm a
long time before a TADS interpreter was. And if someone ever invents a
computer that fits into a contact lens (for a heads-up display), you'll
see a Z-machine for it first, as well.
Adam Thornton
Kevin Venzke <step...@yahooo.frr> wrote:
>"Before Anybody Asks...
>MIME type "application/x-glulx". On the Mac, file type "UlxG", and the
>standard Glulxe interpreter uses creator code "gUlx". "
>
>I don't understand what this means, but is it the origin of the name?
>I don't recall it being an Enchanter spell or anything...
Just be glad it's not called "squoint."
Adam
Adam Thornton
Be on the lookout for _Mentula Macanus: Apocolocyntosis_. About the
time I win the lottery and lose my job all at the same time.
Adam
Dan Shiovitz
>On the other hand, TADS is on its third architectural iteration and
>there are enough differences that you really need three interpreters to
>play the games.
Er, this isn't actually true. TADS-1 games haven't been made for over
ten years, and the TADS-2 interpreters are all backwards-compatible
anyway. So at most you need two interpreters. And on windows and mac
you only need one, since the standard tads intepreter there handles
both sorts of games.
>Yes, the VM's instruction set gets "better" with each
>iteration, but like Java it is strongly CISC (complex instruction set
>computer) whereas the Z-machine is more RISC (reduced instruction set
>computer), which makes it a bit easier to implement an interpreter.
This is true to some extent, but the opcodes aren't really the main
issue keeping people from making interpreters. With TADS 2, it's that
there's no specification written, and the existing interpreter code is
on the hairy side anyway (and isn't Palm-friendly, since it uses too
much stack space). With TADS 3, there is plenty of specification but
it's the extra stuff beyond the opcodes (built-in functions, dynamic
memory, multiple undo, HTML support) making it a bigger job.
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW
Cedric Knight
> Now, I will be my own devil's advocate: I like the idea of better NPC
> interractions (I'd heard that before Eric's post). I already know that
> doing this in Inform will be non-trivial. We'll see.
What kind of non-player character interactions would you find most
useful? New NPC features are currently being added to the next release
of Inform, so now's a good time to say.
Cirk R. Bejnar
> I did a search on "glulx etymology" and wound up in the DM4 index
> (due to "etymology of 'room'"). Not helpful there.
>
> Going to eblong.com/zarf/glulx/ I see:
>
> "Before Anybody Asks...
> MIME type "application/x-glulx". On the Mac, file type "UlxG", and the
> standard Glulxe interpreter uses creator code "gUlx". "
>
> I don't understand what this means, but is it the origin of the name?
> I don't recall it being an Enchanter spell or anything...
>
> Kevin Venzke
It is not the origin of the name, but rather some technical details of
how to describe the file type on different conmputer platrforms.
Zarf, Andrew Plotkin, devised the name out of thin air, if I recall
correctly, but I can't find the reference at the moment.
Cirk R. Bejnar
Greg Boettcher
> What kind of non-player character interactions would you find most
> useful? New NPC features are currently being added to the next release
> of Inform, so now's a good time to say.
For what it's worth, I like the simplicity of the way it is now, as
long as there are plenty of optional libraries with additional
features.
Greg
samwyse
I presume that you've looked at "Programming Conversations with NPC's in
TADS 3":
http://www.tads.org/howto/t3conv.htm
Briefly, NPCs can have states (i.e. sleeping, eating, talking, watching
tv); in some the NPC is non-responsive, in others they are willing to
talk, and in the rest they are actually conversing. Each state can have
a set of topics which correspond to NPC interaction verbs (ASK, TELL,
GIVE, SHOW, etc). The willing-to-talk states can have special greeting
protocols to handle explicit or implicit "hello" and "good-by" commands.
Topics can be turned on and off, and can be collected into groups to be
activated in masse. Two special types of topic groups are
conversational nodes, used to maintain a flow of conversation, and
agendas, which are topics the NPC returns to when no conversation nodes
are active. Finally, there is a "topic inventory" systems whereby some
topics can be flagged to suggest them to the player when they seem to be
at a loss for words and/or in response to an explicit TOPICS command.
The worst thing about the scheme, from the Z-machine's point of view, is
that it requires a large number of objects to carry out, and each object
can use a large number of strings. You could easily start running out
of string space, especially in .z5, and maybe even in .z8. Running
short of objects is also a danger, but switching to Glulx would fix that.
TADS-3 also makes good use of templates to simplify the syntax of
writing all those nodes; Inform would probably need some sort of
pre-processor to translate a consise syntax into more conventional format.
One criticism I have is that the "topic inventory" system doesn't seem
like it would handle large lists gracefully. Inform's ability to group
like objects in a inventory listing could be recycled to good effect.
In TADS-3, a hypothetical TOPICS TALL command might result in this:
You could
ask him about Mary,
show him the gun,
ask him about Tom,
give him the red pill,
ask him about the Titanic,
or show him the photo.
While in Inform I think it could be made to look more like this:
You could
ask him about Mary, Tom, or the Titanic,
show him the gun or the photo,
or give him the red pill.
samwyse
> I presume that you've looked at "Programming Conversations with NPC's in
> TADS 3":
> http://www.tads.org/howto/t3conv.htm
I've looked at the TADS-3 stuff a bit more closely, and discovered that
I may have mildly slandered TADS-3.
> One criticism I have is that the "topic inventory" system doesn't seem
> like it would handle large lists gracefully. Inform's ability to
> group like objects in a inventory listing could be recycled to good
> effect.
Oops, I was wrong. TADS-3 does group topics in the way that I
suggested, giving a result something like this:
> You could ask about Mary, Tom, or the Titanic, show him the gun or the
> photo, or give him the red pill.
I also laboriously copied all of the "Bob" code into a text editor,
using just the final versions of code that was iteratively defined, and
eliminating unrelated examples. In the final version, there are almost
300 lines of code defining over 40 objects, and there are several places
where more work would be required to better flesh "Bob" out as a
character. The code uses are large number of pre-defined clases, as
well, so my worries about having data structures that are too big for
the Z-machine seems well founded. OTOH, several objects could possibly
be replaced by arrays, such as is done in "scenic.h".
TADS-3's tools are better than what's gone before, but looking at the
mass of code that is my copy of BOB.T3, I'm still disappointed. I can't
find the URL, but I recall reading something by Emily Short discussing
how she wrote one of her conversationally intense games. She used a
preprocessor to turn essentially straight textual dialog into Inform
data structures. I've thought about beefing up my own log2inf.pl
program to handle dialog in a similar fashion. Or someone may have to
bite the bullet and create a GUI tool based on Visio or Dia that will
let an author edit conversation networks, and turn those into TADS-3 or
Inform code.
Kevin Venzke
"Cedric Knight" <ckn...@gn.babpbc.removeallBstosend.org> wrote in message
news:41652feb$0
> What kind of non-player character interactions would you find most
> useful? New NPC features are currently being added to the next release
> of Inform, so now's a good time to say.
I'm not an Inform programmer, but... Any chance that
>ASK ABOUT TOPIC
could ever take a stab at guessing who I'm trying to talk to, rather
than saying "You can't see any such thing"?
Kevin Venzke