in next verison of quest i would like some way to make your games so people dont have to download quest but a small fee, can we already do that??

You want a 'version' of Quest that people can play games with without downloading Quest? Hmmm...

yes

In that case you should learn a commercial language likke C++ or C and write a spectacular game worth selling.......

but it would be nicer once your done pay a fee of 20$ and people dont have to download your game and quest just your game

gamemaker wrote;

would be nicer once your done pay a fee of 20$ and people dont have to download your game and quest just your game

If I understand this thread correctly (and it isn't easy to understand!) what you are asking for is a system that allows you to produce an executable 'stand alone' game, rather than a game file requiring the Quest interpreter.

Q1: Why do this? Quest runtime is a free download anyway.

Q2: Why buck the trend? Almost all of the other IF systems make a big point of the fact that their game files are usable unaltered on plenty of different hardware, Windows, MAC, Unix etc. To do this you are obliged to go the interpreter + common gamefile route which is what Quest does anyway. Admittedly Quest's biggest flaw IMHO is that it is Windows only, (so is ADRIFT I think) but that's by the by.

Even if Quest was cross-platform and you went the 'compiled stand alone' route you'd almost certainly have to re-compile your game for each platform you wanted to support. What a p-i-t-a that would be!

If you are determined to do this, use TADS. That WILL let you do what you suggest but be aware that going the stand alone way is strongly discouraged! You might find TADS a 'tad' harder to learn (pun intentional).

Also - I rather doubt you'll be able to actually sell any traditional work of Interactive Fiction these days, it isn't a commercial proposition anymore.

Al (MaDbRiT)

Even though it’s slightly difficult to understand what gamemaker is getting at, I do have to say that I thought of the same thing when I looked into Quest. I don’t see a profit-making opportunity but it would be cool to email a game to someone and say, “Look what I made” without having to tell them that they have to go download Quest and install it before playing it.

MaDbRiT wrote: Admittedly Quest's biggest flaw IMHO is that it is Windows only, (so is ADRIFT I think) but that's by the by.

There are Adrift interpreters that allow people to either play games on the internet (via any browser that supports Java) and others that people using Mac and Linux can use. Maybe something similar could be done for Quest.

That would be difficult because Quest is written in visual basic and VB needs windows to run.
I think Tr0n was making an interpreter in C++ that would be more easily ported to linux.

I would very much like to see Quest ported to Active Server Pages (ASP). That would let it run as a browser-based application which would not require an install. Too, since it is VB, it would be [a little] easier for the developer to port.

Opinions?

Alf wrote;

I would very much like to see Quest ported to Active Server Pages (ASP). That would let it run as a browser-based application which would not require an install. Too, since it is VB, it would be [a little] easier for the developer to port.

Opinions?

I'm in favour! I believe Alex intends to make use of web technology in the form of making the working screen area of Quest html capable in the future so that we can have images etc shown there rather than in separate windows.

Al (MaDbRiT)

thanks for supporting,me i would love it pay a smmall fee for to make it that

Me, too. I wouldn't mind paying an upgrade fee for a browser-based Quest. I would see this as more of a product upgrade than a minor update. I don't work for free, and surely can't expect Alex to!

I thought ASP is the server-side?

I *think* there's VBscript, which you probably have to use in ASP or something. But you should theoretically be able to tweak so slightly the original to fit - I guess.

I was sniffing at the possibility of creating my own ASL interpretter - right now the only interpreting it is going to do is saying "this is/isn't correct". And try to localise the error.

The real trouble of the future is type management... Trying to enable numbers as strings etc.

Theres is VBscript that you would type into a text editor asif it were HTML but ASP is probably better.I'm not completely sure but i think that quest is made in VB6 which, i don't think,doesnt support ASP.The .NET version does though.

francisstokes wrote:That would be difficult because Quest is written in visual basic and VB needs windows to run.

And what do you think Adrift is written in?

There are also a few IF makers that use XML for browser-based games. But, [in my opinion] Quest is a far superior product for functionality.

The marketability of IF games may be a thing of the past. But, it's fun! I sure hope the gamebuilder creators keep their products coming!

davidw wrote:

"francisstokes"

That would be difficult because Quest is written in visual basic and VB needs windows to run.

And what do you think Adrift is written in?

So, what i'm lying?

I'm not saying you're lying. Just pointing out the simple fact that both Adrift and Quest are written in visual basic. So if it's possible for someone to create an Adrift interpreter that works on non-Windows computers, the same could be done for Quest.

Elementary, my dear Stokes.

Just pointing out the simple fact that both Adrift and Quest are written in visual basic. So if it's possible for someone to create an Adrift interpreter that works on non-Windows computers, the same could be done for Quest.

I beileve that ADRIFT's other interpreter is online which makes it possible for quest to do the same, but Quest is far more complex than ADRIFT (not to put it down or anything).

Elementary, my dear Stokes.

Thats why i'm sure it would be far from elementry .

Adrift's other interpreters aren't online. One of them can be, provided you have a browser which supports Java, but they're designed to run straight from the hard drive.

I hope the development of the Quest interpreter in C is still going on.
About online interpreter, I think php is much better (and open source) than asp with is closed (and microsoft) technology.

Davidw wrote;

Adrift's other interpreters aren't online. One of them can be, provided you have a browser which supports Java, but they're designed to run straight from the hard drive

Slightly off the immediate topic here David, but as you are a user of ADRIFT and QUEST perhaps you might like to post your considered comparison of the strengths and weaknesses of the two systems on the chat area of the forum.

I think we are (mostly) aware that there are what I call the 'conventional' code-compile-interpret systems (TADS, INFORM, HUGO & ALAN) and how they are radically different to the GUI based choices, ADRIFT and Quest.

I personally preferred Quest to ADRIFT (last time I looked) because it let me write more complex code the conventional way rather than 'fighting the GUI'- while the GUI is great for the simple stuff. Essentially Quest seemed to offer the best of both worlds.

Al (MaDbRiT)

It would seem that game wise (apart from graphics), theres not a lot that QUEST can't do and thats why i use it.
The point is that it would take a lot of hard coding (from scratch) to make another interpreter because QUEST needs loads of files to run properly, so all the files would have to be crammed into 1 making it EXTREAMLY unpleasent to write and would likely cause errors.
C++ is a language that would do quite nicely for a situation like this because its a lot less limiting than VB (not to say VB is really really limiting though) and probably make the job easier.

MaDbRiT wrote:
Slightly off the immediate topic here David, but as you are a user of ADRIFT and QUEST perhaps you might like to post your considered comparison of the strengths and weaknesses of the two systems on the chat area of the forum.

Al (MaDbRiT)

There's a chat area of the forum? News to me.

Adrift's main strengths: ease of use; straightforward interface; a lot more powerful than most people seem to give it credit for. A lot of the work is already done for you by way of built in commands (which you can override if you want more control). This means you can pretty much download it and start writing your game straightaway.

It's a while since I last opened up the Quest programme, but I remember the last time I tried I gave up after a while because it was just so longwinded to get anything done. The simplest and most straightforward thing takes twice as long as it needs to.

To add a custom command (which is what text adventures are all about really) in Adrift, you simply right click, select "Add Task" and that's it. To do the same thing in Quest, you have to go to Game -> Properties -> Global Settings -> Edit Custom Player Commands and then probably navigate your way through a dozen or so more menus before you find the thing you want... Does it have to be so tiresome? Why not a little "Add Custom Command" icon on the toolbar? I'm also not very keen on the multiple windows that pop up on screen whenever you're adding custom commands, or editing them. Is there a need for two dozen windows which have to be shut down one by one afterwards? Adrift makes do with one window and is better for it. Aside from making the screen look messy, multiple windows just take an age to shut down and make an already tedious process worse still.

Quest might potentially be more powerful than Adrift, but it's unnecessarily tedious to use. The idea behind it is great, but the implementation leaves a lot to be desired, which probably goes a long way towards explaining why it has been around for all these years and yet has still to produce a game of note.

If Quest were given a serious makeover, including the game playing interface which is painfully bad, it could be a definite rival to Adrift, particularly as work on Adrift seems to have slowed to a crawl over the past few years, but in its current format I can't see it ever being anything but the lowest rating of all the IF programmes.

Interesting to read the ADRIFTers p-o-v on Quest and although I don't agree with everything written, I do think you make some valid points.

I share your opinion that Q D K suffers from 'too many windows-itis' when one wants to set up anything other than the most basic features. In fact I've made essentially the same comments myself in an earlier thread somewhere on the forum. Of course with Quest one can always resort to coding by hand to do things for which the GUI is clunky, so perhaps this is not the 'kiss of death' it would be were Quest a GUI only system.

From my (admittedly out of date) research, Quest is potentially a more powerful tool than ADRIFT, but that only matters if someone is actually taking advantage of the extra capabilities.

I think Quest (and ADRIFT) are to some extent both victims of their own ease of use. It is very easy for even a complete beginner to 'knock out a quick game' in Quest or ADRIFT, but you can't really do that with (say) TADS3.

Because it takes a lot more work and knowledge to get even the most basic game written in TADS3 compared to ADRIFT or Quest, the 'first effort' games for TADS are typically the product of a LOT more work than the first efforts of ADRIFT or Quest authors. The almost inevitable result of this is that the worst TADS games tend to be much better than the worst ADRIFT or Quest games.

The knock on effect of this is to make the Quest and ADRIFT systems themselves appear to be markedly inferior, which is probably unfair.

You are quite right though, there really hasn't been a game released that proves Quest can deliver a great I.F. experience. I'm sure that if just one were to emerge it would set the benchmark against which future Quest games could be measured and that this would do wonders for the quality of subsequent games.

To put it another way, at the moment the standard of an average Quest games is pretty low so the assumption is made that this is the quality target / limit for Quest - a recipe for continuing under-achievement.

Following on with that theory, I think the emergence of some rather decent ADRIFT based games has bumped up the expectations of players of ADRIFT games generally. A while back the ADRIFT games emerging were typically pretty poor efforts too, now people expect more, the acceptable minimum quality has risen.

I don't personally have a gripe with the Quest player interface - in fact it was a big part of why I began to use Quest at all, but I do wish there the author could switch off the inventory panes etc and have them STAY off.

Al (MaDbRiT)

The source code side of things doesn't really interest me as I'm not a programmer and probably never will be, so what Quest has to offer me is its GUI... and at the present time, I find the one in Adrift a lot easier and more straightforward to use. If Quest is to be a serious contender to Adrift (and it needs to be at least as good, if not better, if it's ever going to challenge the likes of Tads and Inform), it needs to be at least at easy to use as Adrift is. The wealth of advanced features Quest has are fine in theory, but like you say if no one is making use of them it's a bit pointless having them at all. I haven't played every Quest game out there but I'm pretty confident that 90% of the advanced features have never made their way into a single game so far. Taking them out obviously isn't a good idea, but making them more accessible is. Rather than having to navigate your way through an ever increasingly complicated series of menus and pop up windows, have all the main features on a few toolbars at the top or side of the screen where they can be readily accessed. If there's a way to cut down the number of mouse clicks required to add a custom task from 15 to 2, do it.

From my (admittedly limited) use of Quest, it's pretty obvious it has the potential to produce a decent game but it's lack of user-friendliness is holding it back. The fact that it's been around almost as long as Adrift and hasn't produced anything but decidely below average games is all the proof that's needed that some major changes are required if it's ever going to be regarded as anything more than a programme for writing poor games. One day, someone probably will write a truly great game with Quest... but not in its current format. I doubt anyone has the patience.

If you want to use a GUI, you use Adrift because it's easier to use and get to grips with (and is finally beginning to gain a bit of respect from the rest of the IF world). If you want to code, you use Tads or Inform because they're more respected and people are likely to pay more attention to a new Tads/Inform game than they are a new Quest game.

One of the big problems facing Quest now, of course, is the fact that it has a really bad reputation. Most likely, all anyone outside this forum knows of Quest are the two buggy games released in the IFComps in 2001 and 2002... hardly a glow indictment of what Quest is capable of. A system is generally measured on how good the games it produces are and while that's kind of illogical - it's a system being judged not the individual games written with it - it's a fact all the same. Few people are going to pay attention to Quest while the only games written with it are poor.

One great Quest game, released in the yearly IFComp and getting some favourable comments, would do wonders for the system. All it needs is for someone to actually go ahead and write it...

David you do quite rightly raise a valid point.I also think that QDK's 'million-click-just-to-add-things' is annoying, though to be fair, a custom command can be added in 3 clicks, by clicking the globe icon>selecting the tab>add cumstom commands.

What i would like to see is an option in the "if" section like 'if an object is in another room'.
That would make things like moving NPCs easier as so many people try to write great masses of code trying to make it work, usaly finding errors all over the place (well thats more personal experience ).
It would be almost like checking to see if the object was in the current room:

if <#object#> in <#room#> then {

There IS the option to check if an object is (or is NOT) in the current room - or any other room of your choosing.
Look up IF in the help file - or in the QDK interface look for "if object is in room" (or whatever it's called).

... ANYWAY, Good point on the QDK interface. I think that Alex should continue his refinement of QDK - he has done a nice job in the last couple - to fully utilise nodes etc.
You know, those tree-view's that you use to choose a command/function? That would be good instead of all the IF windows popping up, and would make some sort of sense - it would also display everything on one page instead of hunting through each if to find what you're looking for (I code in Notepad++ right now, so that's only a slight problem for me - nice program which highlights text for you! I've even set it up for 70% of ASL code! ).

The quest GUI shouldn't be so limiting IMO as you are suggesting. What about the handicapped? You may say "why are they playing text-adventure games" but why are you asking that? If you don't like the inventory/object/exit etc bit, then (and I'm admitting Quest doesn't have -) the option is yours - but not the game makers'. I think an option in the Quest properties instead of QDK/whatever is more appropriate.
David, your opinion here isn't as clear as you mix between QDK and Quest, could you make yourself a bit clearer?

Is ADRIFT worked on by a team?
I think that may be the most obvious reason why Quest takes alot longer than ADRIFT - seeing as how I myself have half the day taken away by work, and most of the rest by sleep, I can see why Alex has VERY limited time to work on Quest - especially as it doesn't bring in a major income, and the server probably removes more from his bank than it puts in.

... Now I have to decide whether to pack it in for the night and sleep - or read news articles and perhaps program well into the morning - I bit you adue!

Tr0n wrote:
The quest GUI shouldn't be so limiting IMO as you are suggesting. What about the handicapped? You may say "why are they playing text-adventure games" but why are you asking that?

To be perfectly honest, I haven't got a clue what you're on about there. I never even mentioned the handicapped, so what they have to do with this I can't imagine.

Tr0n wrote:David, your opinion here isn't as clear as you mix between QDK and Quest, could you make yourself a bit clearer?

When I say Quest, I mean the GUI.

Is ADRIFT worked on by a team?

No, one man. Campbell Wild. It would certainly be better if it was worked on by a team but he likes to play his source code close to his chest.

There IS the option to check if an object is (or is NOT) in the current room - or any other room of your choosing.
Look up IF in the help file - or in the QDK interface look for "if object is in room" (or whatever it's called).

I looked but i can't find it.

EDIT:
oh now i know what your saying...the thing is though, it doesn't allow you to check what room the object is in, only if it IS in the current room or it ISN'T in the current room.

Francis wrote;

the thing is though, it doesn't allow you to check what room the object is in, only if it IS in the current room or it ISN'T in the current room

You're wrong there Francis.

You can use the $locationof(object)$ function to find out where any object is.

Al (MaDbRiT)

Oh thanks MaDbRiT, i wasn't looking through the fuctions.

To be perfectly honest, I haven't got a clue what you're on about there. I never even mentioned the handicapped, so what they have to do with this I can't imagine.

Then read on for the next few lines.
I'm going on about your (and Al's) objection to the main Quest GUI, and how there have been objections to the inventory/object/locations/directions side panel - which is hideable at the players request.

I can't see what else you would have gripes over with the Quest GUI. The lack of "skins" I personally think is fine. I mostly don't like skin's anyway, they just make everything seem bulky and slow down your computer just that little bit more.

Before I go off into my own little world, I will stop and ask what exactly you DO have issues with the Quest GUI? How is Adrift's GUI better than Quest's - seeing as how Quest lay's out object/locations/inventory, gives you 8 compass points, one window for the game and one for input..

Tron wrote;

Then read on for the next few lines.
I'm going on about your (and Al's) objection to the main Quest GUI, and how there have been objections to the inventory/object/locations/directions side panel - which is hideable at the players request.

Just to clarify, I'd personally prefer not to have the inventory window visible to the player at all times, but as I said, I still chose to use Quest BECAUSE of the GUI for the player.

I can't see what else you would have gripes over with the Quest GUI. The lack of "skins" I personally think is fine. I mostly don't like skin's anyway, they just make everything seem bulky and slow down your computer just that little bit more.

Agree completely re 'skins', further, I don't understand what is so truly 'horrible' about the Quest player interface either - it's different to the normal 'terminal' looking interfaces for other systems, but I don't see that as neccessarily a bad thing. In fact if you manually turn off the panel to the right, the Quest player looks not that different to the GLK 'WinArun' interpreter for ALAN.

Al (MaDbRiT)

Tr0n wrote:
I can't see what else you would have gripes over with the Quest GUI. The lack of "skins" I personally think is fine. I mostly don't like skin's anyway, they just make everything seem bulky and slow down your computer just that little bit more.

Where did I mention "skins"?

Tr0n wrote:
Before I go off into my own little world, I will stop and ask what exactly you DO have issues with the Quest GUI? How is Adrift's GUI better than Quest's - seeing as how Quest lay's out object/locations/inventory, gives you 8 compass points, one window for the game and one for input..

Okay, I dislike the panels on the right hand side. They're tacky. I dislike having to hide them every time I play a game and would appreciate the ability to permanently turn them off. I dislike the fact that pressing the up arrow doesn't bring back the last command typed - every other system does this, why not Quest? (Yes, I'm aware of F12 but being different for the sake of being different is never a good idea.) I dislike there being no script facility. There doesn't seem to be an ability to load a separate game from within the interface - instead you have to exit, find the game file and load it that way. I'm not too keen on the way items are listed in bold font at the start of the room description unless this is overridden by the game's writer (which very rarely seems to be the case). And I particularly dislike how small the command entry line is. Is there a reason to have it at a size that's painfully small to read? Anything else? Ah yes. Quest only accepts one command per line. Text adventures I played 20 years ago had multiple commands on the same line and there's not another system these days that doesn't have this feature.

I'm sure there are a few other points I could raise but you get the picture. You might think they're relatively minor points, and some are, but I'd be interested in hearing what your take is on why so few people are using Quest despite it being around for a good few years now.

Still curious about the "handicapped" comment as well. Did it mean anything specific or are you just in the habit of dropping in weird comments from time to time?

There doesn't seem to be an ability to load a separate game from within the interface - instead you have to exit, find the game file and load it that way.

You can't load a "new" (by new i mean different) game from the interface but you can load a game you have already saved.

That's what I thought. Is there any reason for that?

Where did I mention "skins"?

You didn't. It has been mentioned before, and it seemed the place to pick up the old goat and throw it in (seeing as how it was about Quest's GUI).

I agree that you should have the option to turn them off perminently. In the property panel somewhere. I also agree about the "up-arrow" issue. I hope that's corrected in the next version as all that really needs to be done is a key-event in the textbox where you enter text (seeing as how Alex already has the last entered text).
I think Alex should have an array of entered commands for this game too - makes it so much easier.

I see what you mean about loading games from inside the gaming window. It's fortunate I don't play many games - or if I do play some, I stick to one.

The default of Quest's room description - i guess a simple scripting bit in the Quest properties (for eg #roomdesc# #objects# #exits# ) would be nice. Being able to order them, remove them, change font effects etc.. Maybe soon eh?

I also agree with you on the text entry panel. If you change the font size than it doesn't change at all, and infact stays tiny. I suppose if you had a resolution high enough (over 1280x1024 - as it seems OK to me, and if you find it hard at 1280x1024 than I suggest a lower resolution is for you) then it would be unlegible.

The many command thingy, just add:

	command <#command#/#command2#> {
		exec <#command#>
		exec <#command2#>
	}

Above any other command in your game. PRESTO!!
Took my 3 hours to actually realise such a simple thing - but whatever .

I think development has been rather slow, and the fact that Quest code can be rather difficult and VERY limiting, that has stopped people using it so much. There's also the market it's aimed at: people who don't know how to program. As they have no idea, they come in asking for a game to be made FOR them - get tired quickly and go away. There's also the reputation (no good games) which keeps people away.

The handicapped comment was in relation to you wanting the GUI changed - the GUI shouldn't be changed radically, rather the OPTION's being there so that we may change it - handicapped people would probably find it simple to use Quest currently.

Tr0n wrote:
I also agree with you on the text entry panel. If you change the font size than it doesn't change at all, and infact stays tiny. I suppose if you had a resolution high enough (over 1280x1024 - as it seems OK to me, and if you find it hard at 1280x1024 than I suggest a lower resolution is for you) then it would be unlegible.

I have my resolution set to 1280x1024 and override the font sizes to make everything slightly bigger for added legibility. But Quest's text entry line seems to remain permanently small. It's not impossible to read, just too small for comfortable reading.

Tr0n wrote:The many command thingy, just add:

	command <#command#/#command2#> {
		exec <#command#>
		exec <#command2#>
	}

Above any other command in your game. PRESTO!!
Took my 3 hours to actually realise such a simple thing - but whatever .

To be honest, I'm kind of baffled why this isn't included in Quest by default. It's a basic ingredient in every text adventure design system, it's possible to do in Quest and yet it's something that has to be enabled by the game writer - assuming the game writer is even aware you can do this sort of thing.

Is it possible from the QDK or only from the source code? By the look of things, it's likely to be a source code only thing.

Tr0n wrote:I think development has been rather slow, and the fact that Quest code can be rather difficult and VERY limiting, that has stopped people using it so much. There's also the market it's aimed at: people who don't know how to program.

I think that's probably hit the nail right on the head. Quest is marketed as a tool for writing text adventures and aimed specifically at non-programmers. Yet to make head or tail of the source code, you need to have at least basic programming knowledge, or be prepared to learn it. And if you're going to learn a programming language, why bother with one that hardly anyone is using and which has a terrible reputation?

Tr0n wrote:The handicapped comment was in relation to you wanting the GUI changed - the GUI shouldn't be changed radically, rather the OPTION's being there so that we may change it - handicapped people would probably find it simple to use Quest currently.

I'm not sure why changing the interface would affect handicapped people one way or the other but then I don't know any handicapped people so...

Personally I'd like ; used for multiple commands - but I couldn't get it to work the way I wanted it to (just pass it to one procedure and call each parameter - pretty nice feature quest has actually) so I chose / instead. Then right at the end of the 3rd hour on my 5th or 7th re-write I got everything working through procedures (seperating the text into bits, then executing each bit).. Then I took a quick glance at the "command" part and thought "I bet I can remove everything and put two lines in there!"... And I could .

I'm guessing it isn't included because it takes a little more work. From our point of veiw it's pretty easy - especially the way I've done it. But the first idea that popped into my head was something TOTALLY off the wall different!
Oh, and there is still ONE trouble with this way... If you type (for eg)
gg/hh/.fsh
then it will do gg and hh just fine - but not even see the "/.fsh" because it has a . in it. I don't know why - but for some horible reason Quest get's rid of it.

... You can do it in QDK. By adding a custom command of "#com1#/#com2#" and then "execute command as if written by player" (or pretty close to that) to execute #com1# and #com2#.
Either that or include a library - I have made one and am actually quite chuffed at how nicely the whole multiple commands work .
[link at bottom of post]

what size screen do you have? Mines a 17" CRT, and it's a bit worse than a TFT (I lurve those TFT's - but have no money for one).
I understand what you mean though, and agree it should scale with the rest of the text.

If you have hand troubles, and use the mouse alot, then not having the object's/inventory can be a really bad idea. There could possibly be more - but that's the one I first thought of.

=========

The library is "ASLGeneral.qlb" and is available in my LibPack. link:
libpack.zip
Has 3 libraries. One I just finished for my current game, it's a help system.
The multiple commands and help system are shown off in 'ASLhelp.asl'.

I use a 17" LCD, native resolution 1280x1024. I've been thinking of getting a new monitor for a while, though, and you can now get 19" monitors for less than what I paid for my 17".

Re the multiple commands on one line idea: do they have to be separated by a slash or could a comma work? A comma is what all the other systems use so if Quest uses something different, no one is likely to make use of it.

A comma could be used by changing the command slightly:

command <#com1#,#com2#> 
{
exec <#com1#>
exec <#com2#>
}

17"-ers are still about $200 (£130) and I'm not going for a smaller one as 1280x1024 has become my preferred resolution. I was a couple of clicks from buying a 17" TFT yesterday, but couldn't be certain about the delivery day - so it didn't get ordered.

I have changed my own files slightly to agree with your "," 'standard', but not the zip file.
I've also changed it so the output would look more like this:

> look,help,south,jump
> look
You are in room1.
You can go south.

> help
Global commands are:

    Command: Run is available...

Local commands are:

    Command: Jump is available...

> south
You are in room2.

> jump
I don't understand your command. Type HELP for a list of valid commands.

Instead of this:

> look,help,south,jump
You are in room1.
You can go south.
Global commands are:

    Command: Run is available...

Local commands are:

    Command: Jump is available...
You are in room2.
I don't understand your command. Type HELP for a list of valid commands.

Which I think is just nicer .

MadRabbit,
You're propabaly right about the IF type games, however. for the multiplayer games, there is still a lot of potential for commercial ventuers. Just check out Skotos. They seem to be doing rather well. And the guy that came up with the GodWars engine, (can't remember his name....Hans something, I think.) he does pretty well with a system that allows donations on his 2nd version of the same engine, Valhalla.
So, if you're interested in charging for you're games, then multiplay is probably the way to go.

Gary

I didn't mean to butcher your screenname, dude. Sorry. Didn't realise 'till after I hit submit. Madbrit, not Madrabbit. lol. Very sorry.

Gary

Alex, I'm just curious, how hard would it be to set up something in quest that could send a player to another url. It could be useful for player in multiplayer games that want to check a message board, or even to jump them into another quest game. Just wonderin' if it would be hard, and also if it's something you might consider putting in the next version.

Gary

I didn't mean the GodWars enginge, duh!! I ment the DIKU engine.

Gary

Im not trying to start anything here, im just saying that if your going to post 4 times, you should just edit the post.
Saves Alex's webspace.

Frank

Your right. That was stupid of me. I didn't think. Wont happen again.

Gary

Don't worry i wasn't having a dig or anything.
It probably wasn't even my place to say anything.