Like Alex I'm a little unclear about what you mean by 'more NPC support'.

Quest is an adventure game programming tool. NPC's are just objects with specific properties and actions, so if you want to have NPC's that can follow the player, randomly turn up and attack him, carry his bag, offer timely advice or whatever, you create an NPC object that does those things.

I'm guessing here, but I suspect what you mean is that you'd like to have ready made "NPC" objects that you can just give a name, set a few parameters (set "attackvalue=100", "strength=25" and so on) and let loose in your game... am I on the right lines here?

If so, the answer is to define a type (or more) of object that embodies what you want from NPC's and then use that (maybe in a library) to create the various NPC's.

As I've written elsewhere, I'm working on a library of 'plug in and use' object types, but admit NPC's (other tan very basic) were not part of my plans.

I don't personally play or like the sort of games where the NPC's are aggressive monsters or whatever that the player battles with, but I accept that others do. If someone would care to assist me in specifying what features an NPC for that kind of game needs to have, I will try to add the functionality to my library of types.

You have the free ranging (where the monster can roam everywhere in the game/level - like DOOM or QUAKE), the Area ranging (so as in FF games monsters are restricted to regions on a map) and there are set pathways (where the monster moves randomly around a set path).

Now IMO the last choice is the best for text adventure's, and certain types of RPG's. There's also the second choice where the monsters are confined to a region which is almost as good - but a bit more annoying - it makes up by having less code to write!

I also want to comment on the size of the game and the length of time it would take to move NPC's around the game (even if some ASL code was specifically added) and wouldn't really be worth it!

You can make the code go faster, and have smaller code, and yes it does take thought - but it also gives you experience and a knowledge of how things work (more) and that's why I don't particularly *like* using other people's code....

Anyway - after straying from the point a bit:
My point is that you only need to think things through for most things to become possible. I think Quest has come along far enough to support some kind of NPC's - it does need a command to see what exits are in a certain room (haven't checked out the latest ASL) for easier coding and less file sizes but that's about the only thing I can think of!