Inform 7’s support for building dynamic data structures is limited, sometimes janky, and in practice, often slow. But it’s so much better than Inform 6’s where even concatenating two strings is a trial.
But by and large, I6 is a cromulent C-like language with some OOP-ish features… and some surprises along the way like: functions that don’t explicitly return a value return true / 1… unless they’re routines embedded as object properties: those default to returning false / 0.
Something that’s less than ideal is that there isn’t an up-to-date comprehensive reference: the manual’s from 2001 and one has to work from it and (primarily) the reference addendum to get a picture of how it stands in the modern world.
ZILF can also compile to z3. Dialog can’t do z3, but it can do z5.
If you’re looking for a robust language that a programmer can love, I recommend TADS 3 over Inform 6. I struggled with Inform, but found TADS to be extensively documented, well-designed, and you can’t not love the debugger.
if you absolutely need to compile to z3 (my question would be why?) then your decision is pretty much made for you: inform/punyinform or ZIL.
inform is well documented (DM4 is out of date but most of what’s in there still applies) and punyinform has excellent documentation and a very helpful group to reach out to.
ZIL is complicated. it has documentation but the bulk of it is from old infocom docs from the 1980s and there are many gaps in that. there is plenty of both modern and old infocom example code available but, for me, it’s difficult sometimes to sort through what’s going on without first knowing ZIL, so kind of a chicken-and-egg situation. also, some ZIL code is actually MDL. on the plus side, there is a helpful group actively maintaining it.
No, but I think @spaceflounder was suggesting this as an alternative to Inform 6 or Inform 7.
The advantage of z3 is that there are retro platforms that support this format, but don’t support z5. However, there are several disadvantages to using z3, e.g. status line issues, no print_to_array, generally no support for UNDO (however, this is up to the interpreter, so there are exceptions, such as Ozmoo), a limit of four items in an array for name and found_in properties.
When I started using PunyInform, I always allowed for conditional compilation to either z3 or z5. As I had a hell of a lot of objects that needed more than 4 items in the name and found_in properties, I had to use routines for those. This bloated the code. At one point, I was getting frustrated with the z3 limitations, so I converted a game from z3 support to z5 only and replaced all those routines with arrays. The z5 file size dropped dramatically. Just saying…
Yeah, the goal of using z3 tends to be folks hoping to maximise the range of retro platforms supported, and possibly sometimes to allow memory-resident tape load on systems with around 32k of RAM. It’s a deliberate constraint chosen to force creative solutions against the limited resources.
Assuming an average of five letters per word and 1 byte per character, 128 kilobytes can store about 25,000 words of plain text. Granted, I have no idea how z3 stores game text, and I’m sure there’s some overhead for game logic that isn’t handled by the z machine interpreter, but that seems like a good, first order estimate of how much game text you can have in a z3 game. Considering 25k words is generally considered a novella for static fiction, I don’t think z3 could handle the IF equivalent of a novel and I imagine one could easily reach the point of needing to make their descriptions as concise as possible just to avoid the size limit.
Though, since TADS was mentioned and stated to not have z3 as a compilation target, what can it compile to, is there a compiler for Linux, and if it compiles to a story file other than gluaxe or zx, is their an interpreter for Linux?
Text storage in Z-machine isn’t great (like Glulx or Å-machine) but also isn’t terrible (like Scott Adams); it generally costs five bits per character, with a bittouch of overhead for padding, and a bittouch of saving through abbreviations.
For one data point, Trinity doesn’t fit in Z3 (and is a decent part of the reason why Z4 onwards has much better control of formatting—Moriarty took the opportunity to invest in better typography!).
Recent PunyInform z3 games where I’ve made an effort to use the best abbreviations have ended up with a text compression ratio of about 0.55, i.e. 100000 characters of text is stored in ~55000 bytes. The reduction compared to the original size is in fact a bit better than this, as I’ve also created string constants for longer strings that are repeated in the code.
Yes, games requiring more than 128 KB in this format are quite conceivable. And yet, quite few of the PunyInform games that are actually released, in z3 or z5 format, come close to 128 KB in size. Off the top of my head, I can’t think of a single one that is bigger than that. Hugo Labrande’s Tristam Island would have been bigger, if he hadn’t done all he could to keep the size down, in order to make it playable on as many retro platforms as possible.
I suspect the 255-object limit bites hardest as z3 games grow. (I have not investigated, but Infocom stayed close to the limit, and modern sensibilities want more implemented scenery than Infocom had.)
You can work around it by reusing objects, but you wind up spending more and more effort on hacks as the game grows.
Indeed, the 255-object limit is an important limitation.
The PunyInform library uses 18 less objects than the standard library. Scenery objects rarely need to have their own objects, but can be represented by a single “cheap scenery” object that follows the player around.
IIRC, the Inform 6 standard library version of Advent uses 278 objects, while the latest PunyInform version uses 222 objects, thanks to the library using less objects and the use of cheap scenery objects. The PunyInform version is ~75 KB in size. If you expanded it with new map sections and puzzles, treasures and NPCs, you would probably hit the object limit for z3 long before you hit the 128 KB size limit.
One way to think about it:
The PunyInform library, as used in this game, is something like 27 KB in size. 7KB of the game consists of the menu telling the history of the game, porting notes etc. The library and compiler creates 8 objects. So, if we don’t count the menu (which doesn’t use any objects BTW), the game code includes 214 objects and is about 41 KB in size. If we’d grow the game in the same style, the game could grow with another 8 KB before we hit the object count limit.
The file format is usually referred to as TADS. The older TADS 2 format has the extension .gam, and TADS 3 uses .t3. The archive has many games in each format.
The official TADS downloads (including source code and Linux binaries) are here.
The best all-around interpreter for TADS is QTads.
But frobtads and qtads may likely already be in your distro’s repositories.
For what it’s worth, I’ve been playing around a little with Inform 6 and PunyInform and so far it agrees a lot more with how I am used to do things. It’s difficult to point to specifics, but I feel like I understand it better on a deeper level, even though I (at this point still) have much less experience with it. Some things that make me go, “Yes!” are
Bare strings are implicit print_rets, so obviously I can wrap them in my own routine if I need to perform another side effect.
Print something conditionally? Sure, have a regular if around it.
Want to make moving north possible only if an action has been performed? Make n_to a subroutine which conditionally returns that location, otherwise false.
Want to count repeated actions? Yup, that’s a regular object property which can be incremented. Want a specific message for each count? Switch statement on the count property.
These things just make so much sense to my programmer brain. I do realise they are all relatively easy to do in Inform 7 too, and I can kinda see how I would do them, but it still comes to me much more naturally in Inform 6. We’ll see how things go as I try more advanced things.
In my case, it’s got nothing to do with that, and is purely a creative constraint. If I cannot make a good game using just 255 objects, I don’t see how giving me more objects would help me. But I need something to enforce that hard limit on the 255 objects, because my discipline is meh.
Ugh, Debian packages qtads(which I’d rather not use due to general GUI aversion and it being qt, which has less mature accessibility support than gtk), but not frobtads, and I’ve never gotten the hang of compiling things from a source tarball.
It’s probably wise to wait/ask for distribution packages of frobtads, as I tried building the current source release 1.2.3 on my Ubuntu 24.04 system just now and got this error:
I was hoping to leap in and say “Oh it’s easy! All you need to do is sudo apt install build-essential and then the ./configure && make commands should just work!” Alas, it seems that getting this built on Debian-derived systems may require a bit more debugging.
…I just now realised you meant Dialog, and not Inform 6. I guess I have to make a proper game using Dialog too so I can compare fairly. (It does look very neat from what I read in the manual.)
