Breaking down a story file with extensions...?

Authoring Inform 7
1

Brand new to Inform and basically brand new to writing IF. This may have been answered already, but for the love of Miracle Whip, I can’t find it.

I dabbled a bit with AGT some years ago and loved it, but reading the reviews I get the sense that Inform is the generally “preferred” way to go. (No offense to the TADS guys out there.) So, I’m trying to cobble some things together. However, coming from a PHP background, this whole “you must cram everything into a single text file” is driving me absolutely insane. While it the pain may ease slightly once the foundation of the project is in place, I’m currently scrolling all over the place trying to update things as it occurs to me that they need to be updated. As heavily as I comment things, it’s even more difficult to find what I’m looking for.

It seems to me that when you “install” an extension, it does absolutely nothing more than copy it to another directory. Inform reads these directories when it opens and allows you to include them in your story file. I see no indication that it does any sort of “pre-compile” or even touches the extensions once it loads except to read the first and last lines and whatever included documentation. I also see no indication that it attempts to actually load the extension file until it compiles the story, which leads me to wonder if editing the extension while Inform is open even matters.

I also looked at the extension files. They seem to be nothing more than Inform “coding” stored in an external file. They can also be edited inside of Inform.

So my question…

Could a project theoretically be broken down into a collection of “extensions” to ease the editing of a massive story file?

For example, say I want all of my “Every turn” rules to go in a single file, so I know exactly where to find them. I want my tables to go in a single file, so I know where to edit them. I want my rule re-writes to go into a single file, so I know where to edit them.

I “install” these “extensions” and include them in my main story file, preferably in an order that doesn’t break the compile. When I’m finished with them, if I don’t want to use them in another project, I move them out of the extensions folder and Inform no longer recognizes them and thus they are “uninstalled”.

Is there a TECHNICAL reason or limitation in Inform that would prevent this from being feasible?

Include Game Name Globals by I4L.
Include Game Name Coversation Tables by I4L.
Include Game Name Turn Rules by I4L.

2

That is what I do.

The main file is the “story”. The rest of it (rules, perversions of rules, tables, etc) are in extensions I create, modify, or both.

For me it keeps the story file clean, and just the story. And it is easier to find things I need to change or add to if they are in clearly named extensions. Sort of like writing in C. Main file has the main routines, the rest of the program is in the include files. To me each is a module, reusable and self contained.

Edit to add: I do keep things that are used as a whole, together. So if I have an extension that requires a table, it is in that extension, not a separate one with just tables. I just find it easier to edit that way as I build it. Though I see no reason all tables couldn’t be in a separate file
(maybe I am wrong in this thinking). But to me, it seems more organized (and easier to edit) to keep things like tables with the code that uses them.

3

Fantastic, that’s exactly what I’d hoped to hear.

Thanks.

4

Make sure you read my edit to add part (see above). Sanity is a fleeting thing. :wink: And to split tables from the code that uses them might be pushing it. In 3 months, you might have to edit both code and table(s). Together, that is easy… separated… especially if there are many tables used by the extension, or all bunched with those from other extensions in the “tables” file… well that could get ugly.

5

I’m pretty used to the database/table being stored in a completely different place from the code. Also, the tables I’m putting together now are pretty specific to certain facets of this project, so I don’t see them being re-used down the road. However, I can see some wisdom in putting the code in the same file as the table and will certainly take that suggestion to heart. As long as it doesn’t violate Inform’s “read things in this sequence” mentality, I’ll probably go that route. Doesn’t seem to, since you’ve been doing it that way.

I definitely don’t want the tables in the main story file, that’s for absolute certain. The ones in question will, in theory, make a certain character behave a certain way based on the “room” he’s in, the current condition of the player, HOPEFULLY the current point in the story and whether or not he’s already said/done that thing before. I can’t think of a better way to do it besides tables, but they’re going to be pretty massive and I don’t want them in the main story file. (To clarify, “can’t think of a better way” translates to “haven’t been doing this long enough to know better”.)

6

I see no reason it couldn’t work, as long as things load and compile in the correct order. Maybe someone else knows another ‘catch’ to this strategy. I know I have to be careful what loads in what order, but so far that hasn’t caused any real problems (yet). :wink:

Ditto, but so far it has worked out fine.

7

Have you noticed that you can jump directly to headings from the contents tab? On a Mac it even hides the rest of the code so it looks as if you were editing a separate file.

(This is of course not the same thing as having separate files, and it’s a personal preference, but I find it easier to use the contents tab than extensions.)

8

Are you using chapters, sections, parts, et cetera?

Using your own code as an extension can be useful if you’re working on some mechanics that you can then apply other projects, but if internal organization is your only issue, then you could try breaking down your code with chapters, and then follow Juhana’s suggestion.

9

Further, having tried this, there are cases where having rooms or objects defined in extensions causes the glulx packager to fail.

10

Exactly, it’s really just a matter of preference. It’s not that I mind using the Index to navigate (and I still do), it’s just that I don’t LIKE having everything in one massive file. I prefer things to be more compartmentalized, if that makes sense. It may be that at some point I decide that this is the better way to go, but for the time being, my brain just doesn’t work that way. :smiley:

Blecki, I don’t think at this point I’m really considering breaking it down that far, though I might tinker at some point just to see what breaks and what doesn’t.

11

I hear you. One of my favorite IDEs ever was an old version of Microsoft Basic (GBasic? QBasic?) that kept every FUNCTION in a separate window. It may have been stored in one file together, but you never saw that.

But with I7, I’ve been reasonably comfortable with the one-big-file approach. I’ve even heard it rumored that it’s a technique used by rarefied uber-geeks.

Here’s the thing for me. I like to separate code and data, but I7 is almost all data. Is a rule for modeling a specific object code or data? The line is especially blurry because text is output by just about every bit of code. (I’ve thought about changing that, perhaps by using Ron Newcomb’s Unsuccessful PC Attempt extension.)

So my general philosophy with I7 is that code goes into extensions and data goes into the story file. I have a middle-ground at the beginning of the story file that contains kinds and verbs that are very specific to the story, but as they get codified and refactored, they move into extensions.

Although source order isn’t all at critical in I7, I try to start with generalities and put more specific stuff later. This helps if I need to trim a file down in order to find a bug - I can usually delete (or comment out) later segments without breaking anything earlier.

There is one major drawback to using one big file on the Mac, though: Typing an open square bracket may result in a very long wait while the whole document gets reformatted. The uber-geeks with one big text file are using vi for the most part, a very fast, very powerful editor. I’ve also considered switching to vi as my editor instead of the IDE, but I like having the index and documentation in the same window.

12

Hm. Should we make a uservoice suggestion to add buttons that automatically drop bracket pairs and double-quote pairs into your file, kind of like the code and spoiler buttons in this forum? So you hit the button, appears (or “”), the cursor moves in between the two objects, and you don’t have to wait forever for reformatting. Think that would be doable?

13

There’s already a menu option to “comment out selection” and it even has a shortcut key (cmd-/). The problem comes up more often from forgetting to use it, or hitting a key by accident. I’d rather focus my requests on fixing the actual problem - perhaps by delaying reformatting when brackets are not balanced, or while the user is still typing.

or… by making other text editors usable as plugins…!

14

How about that! There’s still a problem with quotes, though, and that can’t even be got around by typing the close bracket first.

Anyway, I agree, it would be nice if this didn’t come up.