New I7 Extension for Photopia-style conversation
Michael Martin
that it would also be easy to do traditional Photopia/LucasArts/etc.
style conversation menus. This isn't really the case.
So, I've extended the RQ framework to allow for this style of
conversation and packaged the result as an extension of its own. I've
submitted it to Emily Short and thus it will probably show up on the
Extensions page in due course, but at the moment I have it mirrored on
my own IF site at
http://www.stanford.edu/~mcmartin/if/i7ext/Quip-Based%20Conversation
I hope that it is of use.
--Michael
Ryusui
that number."
Michael Martin
> One problem I noticed: the error response is now "I didn't understand
> that number."
Rats; I thought later versions of Inform didn't do that now. I'll
have to experiment some more with the conditional Understand clauses
to see if I can make it coexist with other things.
Lodestone
As you might gues, I'm quite excited about playing around with this--
rehashing conversation code in the game I'm currently writing looks
like it'll be worth it to allow the greater elegance of this Quipping.
Now I really will have to see if I can get it all in the status
bar . . .
Lx.
Michael Martin
> Now I really will have to see if I can get it all in the status
> bar . . .
If you work out how to make that happen (which will probably require
rewrites of a lot of the stuff that's hardcoded printing in Version 1)
it would be nice to see the resulting code; it should be possible to
reorganize everything so that one can do inline menus (as written),
status-bar stuff in Z-Code (as you want) and separate-Glulx-window
display (like Beyond does) and have it all work just by replacing
rules in some activitiy rulebook.
I don't *think* that's possible now, but I'm not sure how to refactor
it until I have access to two ways of doing it.
So yes; if you work out a way to do this, do let me know.
--Michael
Emily Short
As a first cut, how about:
<code>
Include Basic Screen Effects by Emily Short.
Rule for constructing the status line when conversing:
deepen status line to 10 rows;
move cursor to 1;
if the pertinent quip is not quip_null, follow the perform recap
rule;
otherwise follow the perform QBC recap rule.
To decide whether conversing:
if the pertinent quip is not quip_null, yes;
if the number of filled rows in the qbc_litany is greater than zero,
yes;
no.
</code>
This appears to set the status bar for both z-code and Glulx; it
doesn't do a separate bottom-of-the-screen Glulx text grid, but unless
I'm mistaken, the Windows I7 compiler isn't set up to display such a
thing yet anyway.
Lodestone
Ah, just when you've spent hours slaving on a problem, an angel comes
and magics it away :-)
I'd got somewhere in the general region of Emily's additional code
there, but I haven't yet got onto working out how to splice it with
Michael's, taking out the right bits so that the options print only in
the status bar and not in the main screen. I've also spent far too
long trying to work out how to write a rule that'll work out how many
options are about to be printed into the status bar and deepen the
status bar to that number, rather than having to overstate it and have
an ugly splurge of black space, but I'm banging my head against a
brick wall there.
Lx.
Emily Short
> I've also spent far too
> long trying to work out how to write a rule that'll work out how many
> options are about to be printed into the status bar and deepen the
> status bar to that number, rather than having to overstate it and have
> an ugly splurge of black space, but I'm banging my head against a
> brick wall there.
You'd presumably need to go through the table it was pulling from and
count the number of rows that are filled with something worth looking
at.
I thought about doing that, but when I considered it, I realized I
didn't really like the idea of a status line that radically changes
depth every turn; it seems distracting (though I agree a large number
of blank lines is ugly). Pytho's Mask took a fairly brutal
implementation approach to this: it sets the status line depth to
something fairly small and accepts that it's just not going to be able
to give the player more than four options or so at a time.
Michael Martin
> I'd got somewhere in the general region of Emily's additional code
> there, but I haven't yet got onto working out how to splice it with
> Michael's, taking out the right bits so that the options print only in
> the status bar and not in the main screen. I've also spent far too
> long trying to work out how to write a rule that'll work out how many
> options are about to be printed into the status bar and deepen the
> status bar to that number, rather than having to overstate it and have
> an ugly splurge of black space, but I'm banging my head against a
> brick wall there.
Both of those sound like they should belong in the main extension
themself. Cutting out main-screen displays and the like would really
be best handled by making the display of options an activity, I think,
and then you'd be able to have, for instance, a rule along the lines
of "The default QBC options rule is not listed in any rulebook" and
Just Win. I'll have to experiment some more.
--Michael
Lodestone
Reconsidering, I think Emily's absolutely right--it's far preferable
to take the brutal Pytho's Mask route in terms of aesthetics. However,
it occurs to me that there might be another solution: to set the
status bar to a manageable four lines, and to use the fourth line, if
there are more than three options, to be a <Next> command line for
displaying more options, if more than three are needed. Come to think
of it, didn't Emily's own City of Secrets use something similar, but
with a split screen?--my coding abilities certainly aren't up to that
kind of thing yet, but I should be able to have the status bar do
something like:
(In the status bar)
Reply Options:
1. Yes
2. No
3. Maybe
4. <Next>
> 4
(In the status bar)
Reply Options:
1. It's conceivable
2. I doubt it
3. <Previous>
> 2.
"I doubt it."
On the other hand, I may be getting desperately ahead of myself.
Lx.
Mark Tilford
How's it compare to Simple Chat?
Michael Martin
> How's it compare to Simple Chat?
I haven't done any serious development with either (that is to say,
anything larger than the demo programs), but it seems like SC does
everything with rules by default, while QBC does everything with
(RQ's) tables by default, and requires you to hang rules off of the
quipping activity if you want to get special behavior. I *think* this
may result in Simple Chat running faster, but eating more code space.
I'd have to do much more extensive testing than I have to compare
dynamic memory usage, but at the source code level, QBC ends up
costing two properties per person, four columns of data per line
(worst case - some situations may allow for recycling lines), and one
rule per line with special effects (and a line that can be given more
than once, or that produces new links, counts as a "special effect").
SC appears to cost three rules per line and one rule per character.
QBC also uses RQ's underlying tables for the most part - A large chunk
of motivation for QBC was because people like Lodestone were using RQ
to try to get the same effect, and it doesn't actually work very well
for that. Porting RQ code to QBC code is easier than porting it to SC
because the table that defines the dialogue itself, and the rules
producing special effects from dialogue, don't have to change.
>From a player's perspective, I think the biggest differences are:
(1) With SC, UNDO undoes the whole conversation (I think), while in
QBC, it only undoes one exchange.
(2) QBC by default allows other actions to take place in the middle of
a conversation (and version 1 has a parser problem because of this,
which should go away in version 2).
(3) SC can provide a uniform interface for "say nothing", while a
developer would have to add it by hand in QBC, and it wouldn't be the
Photopia-style "type 0 to say nothing" type.
--Michael
Michael Martin
Odd; I had a lengthy reply but it seems to have vanished into the
ether. A vastly shortened version follows:
The programming interfaces are vastly different, with QBC using tables
for nearly everything and handling special-case information by hanging
rules off of the quipping activity, while SC uses three rules per
exchange and handles the rest with rules.
It's easier to port from RQ to QBC than to SC, which was the primary
motivation for QBC (Lodestone's predicament was not at all unique).
Testing space usage for each would require lengthy experiments and
would also depend heavily on the specifics of the behavior implemented
(if nearly every line of dialogue does something, SC will be a better
choice.)
SC's handling of input, UNDO, and "press 0 to say nothing" tracks
Phototalk; QBC's doesn't, and is closer to Beyond or City of Secrets -
UNDO only undoes one line of dialogue, and you aren't constrained to
stay in "talk mode" without adding a rule performing the constraint.
Both use enums (kinds of value) to represent lines.
Further experimentation is probably indicated. Between SC, RQ, QBC,
all four of the "classic" NPC interaction modes are thoroughly
covered. Eric Eve made some progress on porting the TADS 3
conversation model to I7, but I'm given to understand it is
incomplete. (That didn't stop it from showing up in at least one comp
game last year, though, and it worked out about the same way.)
--Michael
--Michael
Eric Eve
news:1184824368....@m37g2000prh.googlegroups.com...
It's not incomplete, in that it does all it was designed to do. In
addition to the comp game you mention, I used it in an I7 port of
the opening of All Hope Abandon (which was what I actually wrote it
for). So it's complete - but it is a little unwieldy to use, I feel,
so one day I may revisit it to see if I can come up with something a
bit neater.
-- Eric
Michael Martin
> It's not incomplete, in that it does all it was designed to do.
Well, by "incomplete" in this context I meant "It doesn't do
everything the default TADS 3 conversation library does", but I only
have passing familiarity with the full power of that system.
--Michael
Mark Tilford
>
>
> On Jul 17, 8:17 am, Mark Tilford <ralphmerri...@gmail.com> wrote:
>> How's it compare to Simple Chat?
>
>
> (1) With SC, UNDO undoes the whole conversation (I think), while in
> QBC, it only undoes one exchange.
> (2) QBC by default allows other actions to take place in the middle of
> a conversation (and version 1 has a parser problem because of this,
> which should go away in version 2).
Hmm... I haven't been able to test this, but I think you can get effects
1 & 2 if the main quip links to all responses for that NPC, but no other
quip links to any quip. You'll have to type "talk to ____" for each quip,
though (which is how Photopia handled it).
DenizenOfShadows
> that number."
I found that replacing the standard error message "I didn't understand
that number" with something general like "I didn't understand that
sentence" fixes the problem, unless you really need that error message
for whatever reason. I use the default messages by David Fisher
extension to do this:
Table of custom library messages (continued)
Message Id Message Text
LibMsg <number not understood> "I didn't understand that sentence.
[line break]"
I always add line breaks when using that extension.
(I know this thread is old, but I just thought I'd put this out there
in case anyone wanted an easy workaround)