> Of course, these games are meant to make you think. But I find it frustrating, in general, when games leave you "hanging". I've found all kinds of games, from strategy to FPS, that have left me in a spot where I don't know what to do next - drives me nuts!
>

There's a common story among many AGL players. The player gets stuck and frustrated, asks for a hint on the Hints Board, and then dabbles around in the game while waiting for a response. Then, before a response can even come in, the player stumbles on the solution (sometimes within just a few minutes). I don't know if the timing of those successes are coincidental or not (there may be a psychological boost just *knowing* that you won't be permanently stuck, one way or the other), but I think any player that gets past a stuck point this way will ultimately be more satisfied that he did it by himself. Still, anyone who's more "in it for the story", so to speak, will get some help eventually -- just not as quickly as he would with a universal "help" option. I don't mean to characterize everyone -- I do realize that many people also enjoy the puzzles but find them too difficult; however, as long as one is patient he should get enough responses to get past all stuck points.

> Most of these games are quite linear so there must be some way to determine where a player is at and then give them a hint on what to do next... maybe I just need to try and program one and find out!

Yes, I completely agree that it can be done, as I said in my last post. I addressed whether a game author might or might not *want* to have such a feature for the player. But moving past that, let's assume we do.

The degree of non-linearity will matter to some degree, but more so if it's due to puzzles having multiple solutions than if it's due to puzzles being solvable in different orders. I may be forgetting some good examples, but I think all current AGL games are almost exclusively the latter.

Assuming the latter, then if you were designing a "help" option for an AGL game, what you might do first is to draw a game flowchart showing all steps which advance the player in the game and, pointing to each step, all steps which must be satisfied first. Then the task is basically making a long list of conditionals prioritized so that the earliest achievable tasks come first. For example, if your game is completely linear and you need to find some gold, then buy a sword, then kill a dragon, your help option might look like the following (read each "---" as a tab character):

@ help Get some help on what to do next.
---c found_gold=0
------p You need to search around for some money.
---C d:sword
------p Why not use that money you found for a weapon?
---C killed_dragon=0
------p With that sword, you could probably beat just about anything!

Notice that you'd use mostly "C" (else if) conditionals -- you want the *first* (i.e. earliest) satisfied condition to be the topic of the hint. With plain "c" conditionals the option would give you a hint on *everything* you haven't solved yet, even stuff you can't do immediately.

If the game is non-linear but of the second variety (i.e. you can often do many tasks in different orders) then you can intersperse "puzzle lines" in that list -- it would be okay to simply have the conditionals in *any* order which could be achieved. This doesn't make it any more difficult -- the amount of work involved will just be proportional to the overall length of the game. If the game is non-linear of the first variety, on the other hand, your task could be more difficult, as you'd have to account for every possible set of pre-conditions which could allow the player to get past any step.

Now the example style of coding shown above is adequate, but if you had a game with any non-linearity at all, there'd be times where more than one thing could be accomplished next. In those cases you might want the help option to give a hint for a randomly chosen puzzle step from among those which could be next accomplished. This is a bit trickier, but I could explain how to do it if anyone is interested.