I’ve been developing a conversational system for use in my games for the last 5 years.
It started in Halloween Dance, a small speed-IF where I tried out my ideas, which are basically to treat topics like an inventory. So topics are literal items that you carry with you, with some code to keep from doing physical things with them.
This isn’t all that different from normal ASK ABOUT with a topics list, so I refined that in Color the Truth by letting you combine topics. I used that same topic-combining idea in both Absence of Law and Sherlock Indomitable, and I’m currently using it in my Alias the Magpie WIP.
Another user suggested I consider working it into an extension, but I’m not sure how to go about doing that.
How do you make an extension? Do you just write code like you usually would and just name it something else?
How many use cases should you include in an extension? I’ve had cases where I wanted some topics to be temporary and others to be permanent, cases where you need to link things together, cases where all conversation is directed at one person, cases where anything can be said to anyone, and cases where each person has their own topics. Should I include all of these options, and what is the best way to signal/code available options?
How do you keep your code from messing up theirs? For instance, since my method revolves around ‘topics-as-things’, I have to rewrite taking inventory. But wouldn’t that clash with their own inventory code if they alter it?
I know this a lot, but I’d appreciate any help anyone has to offer. Thanks so much!
This is pretty well described in chapter 27. It’s a source file with the .i7x extension. It can optionally have a documentation section (see 27.11.)
Your other questions are trickier. An extension can be focused on a few use cases or a lot of them. (If you can think of a way to separate your functionality into two extensions – a core and an, er, extension-extension – that can be helpful. It can also be a pain in the ass.)
Also tricky. You have to decide whether you’re supporting only this style of game (where the inventory is a topic list), or building an add-on that works in a traditional object-juggling game. Either is legitimate.
The I7 IDE lets you create an “extension project”, which is a lot like a regular project but can pick out the examples in your docs and run them either interactively or automatically, verifying output against blessed transcripts. (Although there’s a bug: it can only find examples that don’t have an author name.) You can use this to test that your extension works as expected and that changes you make to it don’t have unintended consequences to other examples.
It also lets you keep your WIP extension separate from the rest of your installed extensions, which can be useful if you’re already using an older version of the extension in another project and you don’t want to switch over until your WIP is done.
Juggling multiple WIP extensions that depend on each other this way is trickier, though. Careful use of symlinks could go a long way, or you could just copy files around manually if you want to try out the interaction from one extension to another without installing it for all of your projects.
Something else that may be useful is to read through some of the existing extensions with a similar basic theme to yours, both for ideas of what sorts of things are already out there and how they’re internally structured.
Another possibility to consider (though it’ll be harder, of course) is to implement a separate kind of inventory, rather than replacing the default one, so that the two can coexist. Then you can document how to let the final story decide whether to have both, or how to have the topic-inventory replace the standard one if it’s not needed.
Thanks, that’s very helpful. I’m going to try this and see how it turns out! I should mention that my ‘special inventory’ is just hiding the topics from your standard inventory list, not replacing it. I’ll try writing this and hopefully post it in the future!
Inform’s relations system is quite powerful. You can define your topics as a different kind of object entirely, and define a new relation with a knows verb (or whatever else makes sense) so that you can now the player knows about the Ides of March, and get a list of topics that the player knows.
I think you can also mess with the parser scope to make these non-things that the player knows directly parseable, although that’s not something that I’ve played with myself.
This is the sort of thing I meant by a separate kind of inventory, since it doesn’t touch the regular carries relation used by that.
One user-friendly thing here is to put the code that the author might want to replace in a separate section. Then they can include a section of their code in place of that section.
Technically, in addition of what’s been said, I find there’s a bit of a knack to making them in terms of just organising their source. I only have one or two that I’ve published (Menus/Basic Help Menu) but I frequently turn parts of my games into extensions, which has given me practice. The knack includes giving variables safe names that are unlikely to clash with user’s games… stuff like that.
What I have is non-tech advice/observation. I started a CYOA interface extension that never got finished. It was my own idea to start it. I did a really rough version that did what I wanted and then I opened the floor to ideas. I then probably tried to cater to all the ideas, and thought too much about the end user too early. The project bloated hugely and became hard to write, to document and to finish. I never finished it. It could do cool stuff like switch between parser and CYOA interaction with the world model during play, if you’d allow it. I had a version of Cloak of Darkness where you could flip at will.
Mercifully I was able to salvage the bits I liked for the thing I’m working on now, so it wasn’t a total waste of time. I also released one of the handful of examples included in the extension as a standalone game (Captain Piedaterre’s Blunders).
So, systematic extensions are subject to scope-creep. It could come from you or others. Watch out for it! Start with the functions that are most important to you.
