Help testing my conversation extension

Technical Development Inform Extensions
1

So I’ve been working really hard on porting my conversation system from my games to an extension. I’ve written up an extension with documentation and 6 examples, from a tiny one move game to a full ‘minigame’ (a port of my first Ectocomp game, where I developed this system).

I’ve never even installed an extension before, let alone make one, so I could really use help. I’ve been rushing through this, using the tests to make sure it works. I’m sure there are problems.

So I could use the following three forms of help:

  1. Reading through the documentation to see if it makes sense
  2. Trying out the example games to see if they work (beyond the path of the ‘test me’)
  3. Actually installing the extension and making a small sample game, seeing if it makes sense and works

If anyone can help, let me know! I’ve attached it below. If you have feedback, feel free to post it in this thread (or DM if you need to). Thanks so much!

Clues and Conversation.i7x (32.2 KB)

Edit: This doesn’t include the linking system for clues, since people warned me about scope creep. But adding the linking system is very easy (framework-wise), if anyone’s interested, and very time- and work- intensive writing wise.

6 Likes
2

I haven’t looked in any detail yet, but the first thing to note is that in extensions it’s very important to give every single rule a name (by adding (this is the XXX rule) in their headers). This allows the final story to move them around or supersede them as needed, without needing to custom-edit the whole extension.

You should also try to avoid using the story-specific rulebooks – i.e. rather than defining Instead of taking inventory you should instead define a Carry out taking inventory rule and either list it before the standard rules or unlist the standard rules via:

The print empty inventory rule is not listed in the carry out taking inventory rulebook.
The print standard inventory rule is not listed in the carry out taking inventory rulebook.

(This also demonstrates why rules should be named.)

Rather than repeating the same error message in many different rules (that also should probably be named Check rules rather than Instead rules), you should define the text in one place, either with a to say or using named responses. Speaking of which, anything you say in an extension should be inside a rule and given a response letter (e.g. by adding (A) afterwards). This allows the story author to replace the text easily.

4 Likes
3

On a first super-quick scan, I would recommend lumping all the preventing dumb actions thing into a kind of action, so you can make a rule like:

Before action requiring physicality when the noun is a quip (this is the quips aren't physical rule): say "That's not a physical object." (A) instead.

(I may not have got the syntax right.) This would let the author quickly define more objects, consolidate all those rules into one, and make it easier for the author to modify the message using the response system. (Also I suggest using “Before” because that cuts it off at the first opportunity, but that’s not a big deal.)

In general I would like named rules and responses, but that is probably for a later polishing stage! Looks intriguing; I’ll probably try it out soon.

3 Likes
4

Depending on what kinds of thing you want to be able to do with your quips (and what kind of error you want printed if the player tries to use them inappropriately), you could possibly make them a kind of object rather than a kind of thing. That will automatically remove them from most parsing scope so that you can’t do unphysical things with them anyway – though you’d have to explicitly enable the actions that you do want to permit. (That’s actually a change I recently made to Andrew Schultz’ hints extension. Although there it was more clear-cut because they’re not something that the player is ever told the real name of anyway, so they’re never directly referred to.)

I’m not saying that you should do this – your case is different from that one, and it might not be appropriate for you. Just that it’s something to consider.

(Also, you said that a quip is a kind of thing twice. :grin:)

And yes, you can do the named rules and responses later. (Some published extensions still don’t have named responses, although I think it was a requirement to get into the official Public Library at some point.) But I find it helps to get into the good habits early. :wink:

2 Likes
5

This is all very helpful so far. I’ll be working hard on these changes (and any other suggested changes coming in). Thanks!

1 Like
6

A few more thoughts, now that I’ve had a little play with it.

Regarding the definition of everyman – did you try using the existing yourself as a stand-in for the player instead? In most stories (though not all), player refers to yourself anyway – but in those where that isn’t the case it’s fairly likely that your when play begins will run too early anyway, as the story will probably change player in a when play begins rule as well, and by default rules in the story will run after rules in extensions, because they were defined later. There are ways to manipulate this (the easiest being to name it as a “last” rule), but unless there’s some reason why the target has to be specifically the player, it might make sense to just use yourself or some other stand-in object always. Or you could relax the property to an object rather than a person, and then you can use nothing.

I think I mentioned in another thread that I wasn’t a fan of the idea of making the player carry clues/quips around, when there doesn’t seem to be any particular reason to do so, other than scope. I would think that you should be able to handle this a different way that doesn’t require messing with the inventory:

Quip-knowledge relates various people to various quips.
The verb to quip-know (he quip-knows, he quip-knew) means the quip-knowledge relation.
The verb to be quip-known by means the reversed quip-knowledge relation.

After deciding the scope of the player:
	repeat with q running through quips quip-known by the player:
		place q in scope.
		
Quip Repository is a room.
When play begins:
	now every quip is in Quip Repository.

A rule for reaching inside the Quip Repository:
	allow access.

With these definitions in place, now you can say things like now the player quip-knows X or now X is quip-known by the player, or repeat through all quips quip-known by the player, instead of the carried by equivalents (and instead of is nowhere). It also supports a quip being known by multiple people at the same time (in theory, though I didn’t test that). And the original inventory hasn’t been messed with.

(There is a way to handle the accessibility problem without using the Quip Repository, but it’s a little less reliable and uses an undocumented rulebook. This seemed the simpler option.)

If you’re not worried about supporting multiple player characters then you can relates one person to various quips, or instead of using relations at all you can simply declare that a quip can be known or unknown (or some other adjective such as active or inactive). Then rather than quips quip-known by the player you can use known quips.

Fun fact: while messing with this stuff I managed to get the I7 compiler to crash with an access violation, which is a first for me.

As an aside, have you looked at other similar extensions, such as Conversation Suggestions by Eric Eve? (And related ones such as Conversation Responses.)

1 Like
7

Here’s version 2. The advice you guys gave me has made this so, so much better. I can’t say how much I appreciate it!

There’s only one piece of advice I haven’t taken, and it’s just for personal reasons. Gavin, you talked about removing the player ‘carrying’ the quips. I agree that that would improve game flow, but I designed this conversational system to be as close to standard inventory as possible. This is because I believe (subjectively):

  1. Standard Inform code handle dry goods/inventory much much better than conversational topics. Dry goods persist, can be listed, have messages when they are obtained or lost, can be examined at any time, are remembered even when gone, etc.
  2. Making conversation like dry goods will make it easier for players.
  3. Making conversation like dry goods will make it easier for authors to use the extension.

Since that’s my philosophy, keeping the objects carried by the player helps me visualize how I want to code it. I know it’s dumb, and probably makes things worse, and I would be happy if anyone who modded this extension changed that for their own purposes.

Anyway, all of your comments were insightful and helpful. Here is my changelog for v2:

  • Removed extraneous definition of quips
  • Used Gavin’s idea for unlisting old inventory rules
  • Consolidated error messages using Matt’s code
  • Named every rule and message per both testers
  • Changed most rules to check/carry out/report per both testers (except for those replacing old behavior, specifically inventory and examining, as well as the multiple-behavior error message)
  • Changed everyman to nothing (thanks so much Gavin! That really helped me clean out the code)
  • Researched relations more after Gavin’s suggestion, and found a way to use them to let quips have multiple target and to check when repeatable quips have been spoken to everyone.

Clues and Conversation.i7x (35.0 KB)

This extension succeeds when tested against my 6 games and their blessed transcripts, but will almost certainly have errors when used in someone’s game in ways I didn’t expect. Thanks so much to everyone who’s helped so far! I would love any additional comments or help, and appreciate Gavin and Matt’s help.

If no further comments come out for a few days, I plan on publishing. I know there were a lot of different competing repositories before. Is that still true? Where should extensions end up?

3 Likes
8

Right now the Inform 7 extensions site isn’t available, but there is a Library Manager address: extensions@inform7.com.

2 Likes
9

Thanks for this, it’s looking really good and seems easy to use! I’ll try it out in some works-in-progress.

However, I think I found some issues with the current version.

Very minor issues, typos:

  • in the Detective example:
    Watson is a man in the Parlor. The description of Poe is "Watson is interested in everything you have to say."
    → should of course be “description of Watson”

  • in the Eat Your Words example:

The TargetResponse of Dinner is "You say, 'Ahh, such an excellent meal'

'It was lovely, wasn't it?' says Noether. 'Let's get dessert'."

I’d say there’s a full stop missing after “meal”, it should read: "You say, 'Ahh, such an excellent meal.' [...]"

  • in the Halloween example:
    The description of the player is "You're wearing a sppoky ghost costume!";
    → should be “spooky”

  • also in the Halloween example:
    In the TargetResponse of Ghosts, it says:
    "They say that a kid died in this gym 40 years ago at a Halloween party".
    → The full stop should be inside the quotation marks

  • in the source code, in Section 3, there’s:

inserting is unphysical behavior
putting is unphysical behavior

This should probably be “material behavior” like the rest.

Slightly more involved issues:

In the Halloween example, when you take inventory, there are some problems which ultimately stem from the customized inventory rule (which was modified in order to exclude the quips):

You are carrying:
a Your costume (being worn)

“The costume is proper-named.” should solve that, or, with a different modified inventory rule (see below), you’d not need to change the printed name of the carried costume to hard-code “Your costume (being worn)”, but could just do:
The indefinite article of the costume is "your".

If you wear something, it won’t be shown in the inventory.
(Add “The player wears a hat.” to see the issue.)

The contents of carried containers are not shown.
(Add “The player carries a bag. The bag is a container. A piece of candy is in the bag.” to see the issue.)

So, I think, in the quip-based inventory rule you should try to emulate the standard inventory rule more closely, and also include things which the player is wearing.

Fortunately, I think you can stick relatively closely to the standard inventory rule and still exclude the quips, if you do something like this:

Carry out taking inventory (this is the quip-based inventory rule):
	now all things enclosed by the player are marked for listing;
	now all quips carried by the player are unmarked for listing;
	say "[We] [are] carrying:[line break]" (A);
	list the contents of the player, with newlines, indented, including contents,
		giving inventory information, with extra indentation, listing marked items only;
	say "[first time][line break][bracket]You can see topics for speaking to others by typing T or TOPICS[close bracket].[only]";

See Example 177, Equipment List (§6.7. Inventory in the Recipe Book).

I tried this out, and it seems to work nicely.

Another issue, more a matter of opinion:

“Speeching” is not a very naturally-sounding word for the main action, I think. Of course, it is a good choice in the sense that we want to avoid collisions with user-defined actions, but I think some other choice might make for much more naturally-reading code.

How about “uttering”? Then authors could write “Report uttering Okay to Fred” and so on.

I made all the changes above in this version here:
Clues and Conversation - Uttering - v2.i7x (35.5 KB)

(I just renamed it so that I could install them both in parallel)

I tested all included examples with that version again, and they seem to work well.

Regards,
Michael

2 Likes
10

I tried your version, and I’m very pleased with it. I think the inventory solution is much more elegant than mine. One odd effect is that when carrying nothing, it has results different from both my version and standard inform. I made a slight modification to bring it in line with standard inform (possibly an inelegant way of doing it).

‘Uttering’ is great! I tried to use words in the code that are unusual enough not to conflict with what people normally use but that make sense, and ‘uttering’ fills that role much better than ‘speeching’.

Thanks for going to this effort. I’d like to credit you; do you prefer St John Limbo or a different name? (I’ve temporarily uploaded a V3 [based on your version] with that name credited here:
Clues and Conversation.i7x (35.6 KB)
)

1 Like
11

I had the thought “why isn’t this action just called ‘quipping’?” though that may interfere with something else?

1 Like
12

Most of the problem is that I just made this basic idea 5 years ago and redid it for every game, putting stuff in and taking stuff out, and it was never created with the public eye in mind. I’ve been trying to make it more user-friendly and readable but there’s a lot of stuff I’m just desensitized to out of habit. Having fresh eyes on it really helps.

I guess if I had to pick between ‘quipping’ and ‘uttering’, I think I would just rather have something to make it easier for me to distinguish verb and noun while reading.

You know, this whole extension is based off of your game The Baker of Shireton and Plotkin’s Delightful Wallpaper, anway.

3 Likes
13

I mean, I totally love the idea of “conversation inventory” and can see using it to do trippy neat things. You can associate adjectives and rules to specific quips and test for them. “If Inspector Claude has held the belief that Shelly is the murderer…”

This reminds me of stuff I was trying to do much less skillfully in the Big Giant Inform Epic I’ve conceptualized but probably is too unwieldy to actually pull off.

3 Likes
14

When I was working on Threaded Conversation, one of my testers suggested doing this. It turned out that making this change caused the whole engine to seriously chug, though, especially when a lot of quips were iterated through at once. Apparently Inform is optimized for dealing with lots of things at once, but not lots of generic objects.

But that was nearly a decade ago, so a subsequent version of I7 may have improved that performance problem by now.

1 Like
15

Both are optimized, actually, in various ways.

If the quips were out-of-world, I’d recommend using a kind-of-object. (The locale-display code in I7 gets inefficient if there are lots of things in the world. This isn’t a problem for non-things.)

However, since these quips are managed in the inventory, they should be things.

2 Likes