> There's the IF saying that every added object increases the amount of code you must write exponentially, because some player somewhere is going to try this object out on everything he can.

I think it would actually be geometric growth unless you could use arbitrarily many objects in combination with each other at once (which may be the case, for all I know). If you could only use, for example, three objects together in one action, the amount of cases would be O(n^3) with n the number of objects.

> The open format requires you to be "paranoid" (in the words of developer Graham Nelson), accounting for every action the player might try. AGLL, on the other hand, makes "Choose Your Own Adventure"-style IF, which lessens this problem significantly. If the programmer doesn't think about (or doesn't want the player to perform) some action, the option is left out entirely--there's no need to account for it, since it simply isn't there.

At this point, I'd like to not leave out too many of these options. Of course I don't have to implement options of trying objects in places where there's no plausible reason to do so, but I'm bound to miss a lot by not thinking of innovative ways to use objects that players might. And I'll probably get bogged down eventually and just decide not to put more options in because it's taking too long.

> (Sam once said that text-input IF asks "What can I do now?" while AGL asks "Where can I go now?" The first question intrinsically includes "Where can I go," so AGL eliminates one of two major scopes about which the player must worry.)

In practice, AGL does, but in terms of potential, AGLL doesn't. In other post I described how you make a game similar in control to a text-input game (though you couldn't "hide" the available verbs/targets from the player). It's just a bit slower (3 or 4 clicks to select the equivalent of a text-input game's sentence with the same total number of verbs/objects, plus maybe one click of a "constant option" to begin this sequence). Though on second thought, maybe it would be a lot more tedious since AGL doesn't have all that much object-oriented stuff (except the state variable being a location-bound property). You can't ascribe properties to objects, so you'd have to handle each action on each object case by case, rather than handling each action by just the relevant properties of objects.

>
> Last point: to my knowledge, AGLL isn't compiled, but rather interpreted. (This is just a guess.) This would make comparisons difficult, because TADS, Inform, and Glulx are all compiled. (With different versions of compilers, no less, which might also make a difference.)
>

Ah, yeah. Another factor I hadn't considered. Thanks for the information.