> > I remember playing an old text-adventure game where you pretty much walked around in the same few area and did things. How feasible is it to have an AGL game like this?
>
> Possible, but more difficult than it would be with an adventure game that uses text-based commands. In AGL, everything you can do at any given point is printed out on the screen. If you had a game with just four locations that you could move freely among, then in three moves you could get a complete list of everything it's possible to do, and you just pick whichever options look promising. If the same game took command line input, you don't know in advance what things you can do.
>

Well, you could do something much closer along the spectrum to a text-parser game. SOAT will take one small step, but I really could have gone much further with it had I designed it this way from the start. What you could do first is have is a constant option like "Use an item" which would lead to a separate location, let's say 'useitem'. By the way, we can keep track of the *real* location we're at with another variable (let's say v1).

In 'useitem', there'd be all kinds of options like "Use the rope", "Use the red key", "Use the hammer", etc., one for each item you might have. After selecting an option, it sets a variable (let's say v2) to store which item you're trying to use, then jumps to another special location 'action'. In 'action', you have options related to certain verbs, like "tie", "open", "lock", "jump", etc., the availability of which depend on the setting of the *first* variable. Store the option chosen at this step in v3. So, for example, you'd only get the "tie" option if you chose an item like a rope (or anything else which can be tied).

Then, if required, you'd be sent to a third special location, which I'll call 'target'. This would give you a list of options to select a target of the action and item. For example, if you chose "rope", then "tie", you might get the option "pole" if you are in a location with a pole (you'd check v1 to determine this). Store in v4 the target item. Then you jump back to the *real* location by checking v1, and if the combination (v2,v3,v4) is one (such as (rope, tie, pole)) that would work in that setting, you'll see something happen.

You could even make it tougher by allowing every verb to work with every object. This makes the coding simpler *and* makes it almost just like a text-parser game, where the player could try "tie rope to the..." in any location.

Anyway, this is a step beyond what I'm doing in SOAT, but I think it's quite feasible to do in AGL. The thing I worry about the most is that there might be a whole lot of verbs you'd want available to the player. Well, you could split the action-choosing into two steps. At the first step you might prompt the player to choose the first letter of the verb, or a range (such as "a-attach", "attack-bake", etc.) -- then at the second step jump to a location with verbs of that letter. This way, you could easily put in several hundred verbs.

This set-up would of course work well for puzzle steps that work directly on inventory items, and are not dependent on being at a certain location. For example, you could carry around a locked chest, then find a blue key to that chest, then choose "unlock", "locked chest", "blue key" at any time to open it.

Would this system be slower overall than in a text-parser game? A bit, but it depends on how fast your connection is. You'd be making four or five AGL moves to try a complete sentence like "unlock the locked chest with the blue key", and the amount of time this takes varies from person to person.

> For example, what if a particular puzzle involved unravelling a rope to get three thinner lengths of rope, then tying those end-to-end, so you have one long thing rope. Then you lace the rope through the holes on a shower curtain, lashing it to a beam, and poof, you've got some lame kind of makeshift sail for a sailboat. This would work with command line input, but in AGL it would not be so tough. The availability of a "unravel the rope" option gives away the first step -- once you try it (because you try everything in AGL) and see that it works and makes a "tie the smaller ropes together, end to end" option, now the second step is given away. "Lace the rope through the shower curtain holes and around the beam" completes the spoiling of this puzzle.
>

"Unravel the rope" would of course be implemented by something like "unravel", "rope", and might not be obvious to the player as something to do right away, especially with tons of other verbs that might be applicable to ropes. I don't know how I'd do the "lace the rope through the shower curtain holes". Maybe "lace", "rope", "shower curtain holes", if the player could, at a previous step, examine the shower curtain and note the holes.

Trying everything the AGL game allows you to do, in this case, amounts to trying *all* verbs with *all* items on *all* targets in *all* locations/circumstances, and it's now virtually unlimited. You just have a default text message if your attempt to try something fails, like "That won't work here." The game writer only needs to put in work proportional to the number of action combinations that *succeed*.