In every other system I've played games in, it’s been possible to refer to an item by its name and then thereafter refer to it as ‘it’ and have the system understand what I mean. In Quest it seems different. I knocked together a little test game and created a few items: a book, a table and a desk. I had a command to read the book. If I examine the book and follow it with READ BOOK, the command is processed as normal. However, if I READ IT, the game tells me I can’t do that.

On top of that, Quest will often be confused when you use the ‘it’ command after referring to another item. Typing X DESK, GET BOOK, READ IT will have the X DESK and GET BOOK commands work fine, but with READ IT Quest will try to read the desk, despite the last item referred to being the book.

I've also noticed oddities in custom commands where Quest seems to get confused about which item you're actually referring to. I have a custom command to move the book (GET #BOOK#) from the desk into the player’s inventory, but when I attempt to GET DESK as the first command, Quest runs the GET #BOOK# command instead. Is this a flaw in Quest or is there something I'm doing wrong?

For your first point, Quest simply doesn't handle pronouns like other systems.

For the second, that's Quest working correctly. "GET #BOOK#" will match any "get" command; in this case, "book" is just the name of the variable where it stores the matched text, and can refer to any object. To do what you want, either create a command "GET BOOK", or add a "take" tag to the book, or possibly an "action <take>" tag.

For your first point, Quest simply doesn't handle pronouns like other systems.

I had a sinking feeling it might be something like that. Basic rules that are built into all the other systems seem to be absent in Quest. Is there a reason why Quest handles things differently or is it simply a design flaw?

For the second, that's Quest working correctly. "GET #BOOK#" will match any "get" command; in this case, "book" is just the name of the variable where it stores the matched text, and can refer to any object. To do what you want, either create a command "GET BOOK", or add a "take" tag to the book, or possibly an "action <take>" tag.

That explains another problem I had been having: namely two OPEN #ITEM# commands where only the first would work and the second be ignored. I’d assumed there was some flaw in Quest’s design that made it incapable of handling more than one command of the same type, but oddly it looks like Quest is *intended* to work this way.

Well, I guess my query as to whether it’s any easier to write a game in Quest now than it was the last time I tried (several years ago) has been answered. No wonder so many of the games written with it are so bad.

The first is a problem with Quest. The second is you misusing Quest.

Whenever you use a command, the following code must handle _every_ input that matches it.

So the correct way to do it would be more like:

command <open #@item#> if (#item# = box) then {
 ... 
}
else if (#item# = closet) then {
 ...
}
else msg <You can't open that!>

OR

command <open #@item#> if action <#item#; open> then action <#item#; open>
else msg <You can't open that!>

and defining open actions on the appropriate box and closet

OR

command <open box; open cardboard box> ...
command <open closet; open door> ...

I don't quite understand what your first problem is. But I think it's because you're not using an object variable in your "read" command (I assume you're using a command rather than a verb? Things should work automatically very easily if you use verbs).

If your "read" command looks like "read #@object#" then you'll be able to use "read it".

Ok, I had the custom commands down originally as SMASH #@DOOR# and SMASH #@DESK# and so on, but Quest seemed to have problems with this in that only the first command would be processed, so I changed them all to SMASH DOOR and SMASH DESK. I've tried changing them back and I get:

> X DOOR
A LARGE DOOR, CURRENTLY LOCKED, AND WITH A CERTAIN FIRMNESS TO IT WHICH INDICATES THAT BATTERING IT DOWN WILL, AT THE VERY LEAST, BE A DIFFICULT TASK.

> SMASH IT
VIOLENCE SOLVES NOTHING.

USUALLY.

HERE, HOWEVER, IT WORKS A TREAT AND ON YOUR FIRST BLOW, THE DRAWER FLIES OPEN AND SOMETHING TUMBLES OUT AND LANDS ON THE FLOOR WITH A SOFT TINKLING SOUND.

Quest seems to get confused about which item I am referring to. Later I get:

> X DRAWER
OF THE DRAWER ITSELF, THERE IS VERY LITTLE FOR YOU TO SAY ABOUT IT. OTHER THAN IT BEING CLOSED. AND LOCKED TO BOOT.

> SMASH IT
YOU PUMMEL THE DRAWER SOME MORE. THIS ACHIEVES PRECIOUS LITTLE IN THE LARGER SCHEME OF THINGS, BUT AT LEAST IT GIVES YOU A VALUABLE OUTLET FOR YOUR FRUSTRATION.

> GET IT
YOU TAKE THE BOTTLE FROM THE DESK.

Which is even more confusing.

How odd. Could you paste or attach your code here (or just the relevant bits) so I can take a look?

' "Escape The Fiery Hellhole Of Doom"
' Created with QDK Lite 4.02 - UNREGISTERED VERSION

!include <stdverbs.lib>

define game <Escape The Fiery Hellhole Of Doom>
	asl-version <400>
	gametype singleplayer
	start <study>
	game author <David Whyld>
	game version <1>
	game info <Created with QDK Lite 4.02 - UNREGISTERED EVALUATION VERSION.>
	default fontname <Calisto MT>
	default fontsize <12>
	background <black>
	foreground <white>
	startscript give <diary>
	command <w> msg <Darn! He's only gone and locked the door. Well, that's a bother. You'll just have to wait for him returning.>
	command <open #@door#> msg <Locked. How very odd... you never heard him lock the door and you can't imagine why he would even want to lock it. You'll have to have words with Mr Grimes about this when he returns.>
	command <about> msg <"Escape The Fiery Hellhole Of Doom" - a lighthearted comedy game by Sam Spade* which shouldn't pose too many problems for people assuming a) they're good at text adventures, b) they're persistent and c) they cheat. |n|n* Not my real name in case you haven't guessed.>
	command <hint> msg <The first thing you should do is: examine things. Examine everything you can find. If it's mentioned in the room description, or in the description of another item, it can be examined. Examining things is the key to solving the game.|n|nThe second thing you should do is: understand how the game works. You can use items (with the USE [item] command funnily enough), put them on other items, break them, and so on. |n|nThe third thing you should do is: try to alter your environment. Move things around, try and find a way out of the study, try and attract outside attention. Sooner or later, things are going to come to a head and when that happens, you really don't want to still be in the study. Trust me you don't.|n|nIf you're really, really stuck, the CLUES command should provide you with a few pointers. There's also a walkthrough command... but you'll need to figure out how to activate that one yourself. And no, it isn't WALKTHROUGH.>
	command <smash #@drawer#> {
		if ( %drawer% > 0 ) then msg <You pummel the drawer some more. This achieves precious little in the larger scheme of things, but at least it gives you a valuable outlet for your frustration.> else {
			msg <Violence solves nothing.|n|nUsually.|n|nHere, however, it works a treat and on your first blow, the drawer flies open and something tumbles out and lands on the floor with a soft tinkling sound.>
			set numeric <drawer; 1>
			move <watch; study> }
	}
	command <walkthrough> msg <You try to cheat by accessing the WALKTHROUGH command but instead a voice murmurs, "Ha!"|n|nClearly the author is a step ahead of you here.>
	command <smash #@door#> msg <You're only a lighty-built fellow whose main form of exercise is turning the pages in a rather large book on stamp collecting you're currently reading, so battering down a door? Sorry, but not going to happy.>
	command <z> {
		if ( %wait% = 0 ) then {
			msg <You wait.|n|nA sense of unease begins to gnaw at you. Is it a good idea to wait here for the rather intimidating Selston Grimes to return? Something tells you it isn't. Something tells you, in fact, that getting the heck out of here might be a very, very good idea right now.>
			set numeric <wait; 1> } else {
			if ( %wait% = 1 ) then {
				set numeric <wait; 2>
				msg <No, waiting is bad, you decide. If you wait too long, you're sure bad things will happen to you.|n|n(You aren't really sure what these bad things will entail, but you're reasonably sure that they won't be pleasant.)> } else if ( %wait% = 2 ) then msg <No, waiting is bad, you decide. If you wait too long, you're sure bad things will happen to you.|n|n(You aren't really sure what these bad things will entail, but you're reasonably sure that they won't be pleasant.)> }
	}
	command <read #@diary#> msg <You flip open the diary and read a note your secretary left for you:|n|n"15th June 2008 - Meeting today with aspiring author Selston Grimes, recently released from prison after serving 18 consecutive life sentences for murdering book publishers. Best tread lightly around him."|n|nHmmm... you're going to have to speak to the silly girl about letting you know these things beforehand.>
	command <open #@drawer#> if ( %drawer% > 0 ) then msg <You fumble with the drawer for a moment or two, trying in vain to open a drawer that is already open.> else msg <You open the drawer. Or, actually, you try to open the drawer but it seems Selston, clearly not trusting you to not go rummaging around in his desk, has locked it. After rattling the drawer in vain for a few moments, you are forced to concede defeat.>
	command <get all> msg <Unfortunately, the ALL command is not recognised by Quest.>
	command <drop all> msg <Unfortunately, the ALL command is not recognised by Quest.>
	command <clues> msg <It was perhaps somewhat nasty of the author to imply that a clues command would reveal, well, clues about the game and then, instead of said clues, merely display this block of text for the player to read. But it seems that's what happened. Oh well.>
	command <get #@bottle#> {
		if ( %desk% = 0 ) then {
			msg <You take the bottle from the desk.>
			give <bottle>
			set numeric <desk; 1>
			reveal <bottle> }
	}
	command <put #@bottle# on #@desk#> {
		if got <bottle> then {
			msg <You return the bottle to the desk.>
			lose <bottle>
			set numeric <desk; 0> }
	}
	command <calm #@fire#> if ( %fire% = 0 ) then msg <Easier said than done.> else msg <The fire is already as calm as it's likely to get.>
	error <badcommand; Sorry, that command isn't recognised.>
	error <badthing; You cannot see that here.>
	error <badplace; There is no exit in that direction.>
	error <defaultuse; You can find no use for that.>
	error <cantdrop; You cannot drop that.>
	error <badtake; You cannot take #quest.error.article#.>
	error <badgo; To GO command does not work here. Selston Grimes' study is a bizarre one, if the truth be told, and does not respond well to the GO command.>
	error <defaultlook; You see nothing special.>
	define variable <wait>
		type numeric
		value <0>
	end define
	define variable <drawer>
		type numeric
		value <0>
	end define
	define variable <desk>
		type numeric
		value <0>
	end define
	define variable <fire>
		type numeric
		value <0>
	end define
end define

define options
	debug off
	panes disabled
end define

define synonyms
	west = w
	east = e
	north = n
	south = s
	unlock = open
	exam = x
	ex = x
	info; information = about
	batter; bash; destroy; kick = smash
	help; hints = hint
	wait = z
	place = put
end define

define room <study>
	description <|b|uThe Study Of Selston Grimes|xb|xu|nThe study of Selston Grimes is a rather grim and foreboding place, hardly the sort of location, in all honesty, you'd have expected him to leave you while perusing his new 'children's' book. There's a large fireplace warming the room, an old oak desk, several bookcases (minus any books, funnily enough)... and the dead body of his last wife, preserved in some kind of preservative goo, standing in the corner and staring at you with an expression on her face that looks entirely too alive for someone who has been dead for the best part of a decade. It's all quite grisly.|n|nThe only exit appears to be to the west.>

	define object <door>
		look <A large door, currently locked, and with a certain firmness to it which indicates that battering it down will, at the very least, be a difficult task.>
		displaytype <Object>
		article <it>
		gender <it>
		invisible
	end define

	define object <diary>
		alt <your diary>
		look <A rather battered little diary you keep with you at all times and find handy to jot down your thoughts in.>
		take
		prefix <your>
		displaytype <Object>
		article <it>
		gender <it>
		drop msg <You debate leaving your diary lying around but can't really find any good reason to do that.>
	end define

	define object <desk>
		alt <oak desk; old desk; old oak desk>
		look if ( %desk% = 0 ) then msg <A monstrously oversized desk. To you, this screams of either a man intent on impressing guests with the sheer size of his desk, or, perhaps, simply someone who really a rather big desk in a sale and figured he'd buy it.|n|nThere is a drawer set into one side of it. The only thing atop is a bottle.> else msg <A monstrously oversized desk. To you, this screams of either a man intent on impressing guests with the sheer size of his desk, or, perhaps, simply someone who really a rather big desk in a sale and figured he'd buy it.|n|nThere is a drawer set into one side of it.>
		take msg <The desk is far too heavy for you to take it.>
		prefix <an old oak>
		displaytype <Object>
		article <it>
		gender <it>
		invisible
	end define

	define object <drawer>
		look <Of the drawer itself, there is very little for you to say about it. Other than it being closed. And locked to boot.>
		take msg <The drawer is fixed into the desk and you can't take it.>
		prefix <a>
		displaytype <Object>
		article <it>
		gender <it>
		invisible
	end define

	define object <watch>
		look <A scratched watch which looks to have been old when your parents were young (and your parents have been old for as long as you remember. Even when they were a relatively young couple, they still seemed middle-aged). It seems to work - just about - but the strap is broken so the watch can't be worn any longer>
		prefix <a>
		displaytype <Object>
		article <it>
		gender <it>
	end define

	define object <fireplace>
		look <The fireplace is larger than is strictly necessary for a room of other quite modest dimensions and generates entirely too much heat for your liking. Or the fire inside it does anyway. The fireplace itself, being made of stone, doesn't generate much heat at all.>
		take msg <The fireplace isn't something you can take.>
		prefix <a large>
		displaytype <Object>
		article <it>
		gender <it>
		invisible
	end define

	define object <fire>
		look <The fire is a little too bright and a little too hot for you to look at it directly. You'd need to callm it down a bit before you could study it more closely.>
		take msg <While an excellent way of getting burnt, you aren't sure what purpose would be served by this.>
		prefix <a>
		displaytype <Object>
		article <it>
		gender <it>
	end define

	define object <bottle>
		look <The bottle appears to contain something that might well be blood. Or, of course, it could simply be some other substance that is a little dark in colour.>
		take
		prefix <a>
		displaytype <Object>
		article <it>
		gender <it>
	end define

end define

define text <intro>








Well, you had to confess, the title was certainly unusual for a children's book: "Escape The Hellhole Of Fiery Doom". Purporting to be a whimsical tale about a group of children who embark upon a grand quest to uncover a magical pot of gold, it actually seems to be... well, a bit different than that actually. Partway through the first chapter, at about the time when little Timmy Jenkins, the hero of the tale, gets his head lopped off by a sword-wielding ogre who then proceeds to kick it around the ground to the amusement of his fellow ogres, you begin to suspect that this isn't the kind of story that is going to go down well with your readers.

Hmmm... No, your readers won't like it at all. Unfortunately, you get the distinct impression that Selston Grimes, the manuscript's author, might not appreciate you telling him this...
end define

You're misusing Quest, which is why you're having so much trouble. (Probably you're trying too much to write things in the same way you'd write it in ADRIFT.)

1: When you're writing commands, try giving the variables neutral names (so <smash #@noun#> instead of <smash #@[email protected]>) to avoid internal preconceptions.

2: Only the first command that matches will run. It must handle any possible situation.

3: Commands defined in <game> can run anywhere; unless you're designing a one-room game, the command given for <w> isn't what you want.

4: As much as possible, try to put the interesting parts into actions instead of commands.

You'll find it easier to use verbs instead of commands for things like "smash drawer". If you go to your drawer object and add the verb "smash" to it, you can put your script in there.

This will automatically make "look at drawer" followed by "smash it" work, and it will give a sensible default response when the player tries to smash something else. And you won't have to worry about any variable names or any of that nasty "#@" stuff.

Also putting the bottle on the desk would be much more neatly handled if you set the desk up as a surface (on the Container tab in QDK).

Ah, thanks. I figured there was something I was doing wrong.