From the Non-Comp Review Project:



Attempted Assassination by Matt Slotnick
Platform: Quest
Download: Baf's Guide
Additional links: SPAG's original copy of this review
Reviewed by Greg Boettcher

[This review was previously published in SPAG #43. Reprinted with permission.]

This was the first Quest game I've ever played, and my goodness. I have to start by telling what I've observed about the Quest system before I go on to review the actual game.

The Quest System

Some people might only barely consider Quest games to be interactive fiction. Although you can type in commands, the range of commands is extremely limited. From what I could tell, Quest is used mostly to make adventures that can be solved by using no verbs other than "look at," "examine," "take," "drop," "speak to," "give," the ever-popular "use," and the directional verbs such as "north" and "south." To input these verbs, you can type them in, but you can also input them via a graphical user interface on the right side of the game window. Also in that part of the screen there is also a list of nearly all the objects you can interact with. By clicking buttons and dragging various words, you can do 90% to 100% of everything you need to do to win a Quest game, without the need to type anything, and without the need to use any verbs not listed above.

In the game I played, I only found one case where a non-standard verb was implemented. In the case of one noun, it actually does work to type "open noun." But this verb was implemented badly. If you try to "open X", where X is almost any other noun, you get the same response as if you type "asdf X".

Thus, it is not very rewarding to spend much time using non-standard verbs in Quest games. There is no illusion of being able to try to do anything you can think of to type. As such, I would expect most people to almost always use the click-and-drag interface on the right-hand side of the screen. This is IF at its most rudimentary; in fact, it is barely IF at all.

Aside from verb problems, there was also a tendency for noun problems, at least in the game I played. If you want to take a beach ball, for instance, "get ball" might not work; you might have to type "get beach ball." Not very impressive.

As a result, the level of interaction in a Quest game is not adequate. At best, it feels like a graphical game with a clunky interface. But to me, having a trimmed-down interface without graphics is like having the thorn without the rose. And when it comes to interpreting textual input, Quest does a bad job.

Attempted Assassination

I keep thinking to myself that, to be fair, I should not ask whether Attempted Assassination is good, but whether it's good as a Quest game. On this basis, I have to ignore the game's shallow interactivity, bad parsing of verbs, bad parsing of nouns, clunky interface where almost all interactive objects are listed, etc. By Quest standards, is Attempted Assassination good?

Well, the game begins when you wake up at 8:05, already late for work. You run to the car, arriving there at 8:08. There you find a note that says, "Your car will detonate at 8:08 this morning. Have a nice day!" So you hightail it out of there, seconds before the explosion. Then, later, you find out that the bomb was planted between 8:00 and about 8:02. My, but your guardian angel was quick at writing that note! Ah, the realism.

In another part of the game, you chase a suspicious man, who jumps through a window. You follow him until you have him cornered. Finally he says, "I don't know of any bombing on your car. I jumped out of that window because I dropped my watch." How do you respond? You say, "Oh, sorry to have bothered you then."

These cornball events might make you roll your eyes, or they might make you laugh. But even if there's some humor here, how are you supposed to enjoy it when the game is so sloppy and badly designed? The game contains rooms named "room03" and other such things; there are gruesome spelling and grammar mistakes ("no where in side" should be "nowhere in sight"); there is a car that you can't drive, but behaves for all the world like a door; and so on.

No, I can't call this game successful even by the standards of what Quest could achieve. And even if it was good as a Quest game, that would still make it pretty far from being a good game.

On the other hand, this was the author's first game. The good news is, there's plenty of room for improvement.



ESPER: The Secret of Drom Bennacht by Ian McDermott
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

Considering this was the third Quest game I'd played in a row (and the previous two had been the worst games I'd played this year), I wasn't expecting much from ESPER: The Secret Of Drom Bennacht. But I was pleasantly surprised.

You're a psychic investigator called to the castle of Laird Jonathan Winters, a man who claims to have heard the cries of the Bean Sidhe, the mythological banshee. Only when you arrive at the castle, the Drom Bennacht of the game's title, it's to find Laird Winters brutally murdered and his father raving that the banshee is coming for him. No one else seems willing to try and solve the murder so that leaves just you...

For a Quest game, this is surprisingly well implemented. Most of the items mentioned in the room descriptions can be examined, NPCs can be spoken to (the dialogue is repeated each time you speak to them unfortunately) and the puzzles, while hardly inspiring, at least show promise. And the standard of the writing is well above average for a Quest game.

But just when I was thinking that this might actually be a decent game after all, it went and crashed on me. There's a record player in the music room that, when you try to examine it, produces an error message and crashes the game. Up to that point, I was quite enjoying ESPER. Oh well...

Another go at the game revealed a few things I'd missed the first time, but I also noticed that the further into the game I progressed, the less attention to detail there seemed to be. Whereas most of the items mentioned in the early room descriptions can be examined, a good number later in the game can't be, including one particularly one bad point where I was trapped underground in a three room corridor littered with items that couldn't be examined, taken or interacted with in any way, shape or form.

Conversation is handled via the "talk to [name]" format which produces a little dialogue box in the middle of the screen to choose your conversation options from. While this beats the guess the verb nightmare that is "ask [name] about [subject]", it needs updating whenever the player discovers new information about something. I discovered the secret behind the banshee yet was unable to tell anyone about it. I was also unable to question people about things. Frustrating.

Overall, ESPER is one of the better Quest games that I've played but unfortunately that's not really saying much. It's far better written than your average Quest game, has better puzzles and an actual storyline, but there are a good number of things about it that need fixing before it could ever be called a decent game.

4 out of 10



The Former by DirkW
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

Straight off I ran into problems with this game. The first room description displays some text that keeps telling me I've just woken up – shouldn't that have been part of the introduction and not an actual room description? A room description, after all, is supposed to describe what's in the room, and this one doesn't. I'm also advised to ask my Data Assistant (whatever that is) a series of questions but no matter what I typed, I couldn't get a response. For that matter, I couldn't even see my Data Assistant.

The game doesn't really seem to have any kind of storyline. You wake up on the floor of a factory unable to remember anything. That's about it. Most of the game – that I managed to reach anyway – involved wandering around the factory and solving such puzzles as figuring out the exact right wording for opening a locked desk with a key. (OPEN DESK doesn't work, nor does UNLOCK DESK or OPEN DESK WITH KEY or UNLOCK DESK WITH KEY. By the time I hit upon USE DESK KEY ON DESK I was just about ready to slit my throat.)

Elsewhere I found several locked doors but the game didn't even understand either the OPEN or UNLOCK commands. Sheesh. You'd think that out of all the commands a writer might think to implement in his game that OPEN would be one of them. But not here unfortunately.

There was very little text in the game but what bit there was seemed to be littered with spelling mistakes and grammatical errors. There were also missing words, making some of the sentences jarring to read. Did the writer bother to read through his game before uploading it? I suspect not.

My total time spent playing this game was perhaps a little under twenty minutes, hence this fairly short review. But The Former, in its current state, is just about unplayable and twenty minutes was more than enough for me.

1 out of 10



Haunted Horror by Matt Slotnick
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

Another Quest game that seems barely even finished: spelling mistakes in the intro, grammar errors and a general writing style that doesn't do the game any favours at all.

You're a detective who has received calls saying there are strange goings on at a house in the middle of nowhere so you've gone to investigate. Ho-hum. With enough depth, that might actually be a reasonably decent idea but here it's just given all the attention to detail of a quickly jotted down shopping list. It's also a remarkably similar idea to the intro to ESPER in which you're a detective called to investigate a castle in the middle of nowhere. It was done a lot better in ESPER.

The usual errors hit you right from the start: capitalisation where there doesn't need to be any; clunky room descriptions "There is Door here"; a folder which is described as being on the passenger seat of your car even after you've picked it up and dropped it in another location; a man described as "the man who is in the house"; a TV with the description "a TV"; and so little to do it's like the author just wrote a bunch of very empty locations, linked them together and then decided he was finished with the game and left it at that.

"What are you trying to do?" pops up on screen every few moves in relation to something I've tried but which the program hasn't understood. WATCH TV isn't covered, nor is OPEN DOOR, nor is READ PAPER... Getting Quest to understand a simple command is often a trying experience.

As with just about every Quest game I've played, there are no hints and no walkthrough. I became stuck very soon and the lack of hints/walkthrough meant this game got pushed to one side pretty quickly indeed. With a better game I might have tried harder, but for Haunted Horror I was only too happy to see the back of it.

1 out of 10



King's Quest V - The Text Adventure (Part 1 of 2) by Steve Lingle
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

There were bits of King's Quest 5 – a text adventure remake of the old classic – that I really liked, and other bits that just had me climbing the walls in frustration.

Now I'd never played King's Quest, so I wasn't sure what to expect from this game. I knew a bit about it: a generic fantasy quest populated with generic fantasy creatures in a generic fantasy world. All well and good. I've been a fan of that sort of thing. So enter King's Quest 5 which is as generic as you're likely to get.

Descriptions tend to be short and to the point, but have a kind of retro charm about them that I liked. Playing this reminded me (nostalgically) of the text adventures I played as a teenager, back in the days before computer memories grew huge and you only had a few lines into which to cram as much descriptive text as possible. You don't get that sort of these very often these days which in some ways is a shame.

There are bits about the game, though, that just about had me tearing my hair out in frustration. From time to time, a message flashes up on screen advising you that you've just reached a particularly dangerous bit of the game and asks if you want to save your game. Now the first time I saw this, I thought "hey, neat idea!" as it stops the player unwittingly going and getting himself killed. But the message then flashed on screen every single time I went that way. And when I came back. Even if I went just east then west, I'd get the message asking me if I wanted to save the game. Twice. By the time I'd seen this for the tenth time, I had stopped thinking "hey, neat idea!" and started thinking "*&##@!!!" (or words to that effect). Wouldn't it have been a better idea to just have this flash up on screen once? Or only a certain number of moves?

There are times when Quest makes you want to scream. Upon restoring a saved game, the introduction is displayed once again before jumping to the point you actually saved at. I don't know of any other system that does this and having to page through the text every time I died and then restored my saved game position (which was often as instant death lurks around many corners) was a major pain. Then, too, there's the annoyance of having to press F12 to repeat the previous command instead of the up arrow favoured by every other system. And don't get me started on the fact that you can only recall the previous command (and none of the ones before), and the lack of an undo feature...

Overall, King's Quest 5 is probably the best Quest game ever written... unfortunately, considering the rest of the Quest games on offer, that's not saying much. Written with any other system, it would be lost amidst other, far better games. Some of the fault lies with the author (his save game warning wears thin after the first few times, and killing the player off as often as happens here is never going to go down well) but at least some of the faults lie with the system itself, and this game, more than any other, indicates that Quest, however many nice and fancy features it has, just isn't up to the task of producing a truly great game. Even in the hands of an above average writer, its flaws are apparent to anyone using it for more than a few minutes.

4 out of 10



The Last Detective by Catalin
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

The first thing I noticed about The Detective is its truly awful colour scheme. Here we have miniscule red text on a glaring bright blue background. Ouch. Is the writer colour blind? Unfortunately one of Quest's many failings is that it doesn't allow the player to alter the colour scheme so this is something you're stuck with. (Although there's an option from the Debug bar at the top of the screen to change the colour, it doesn't work.)

After squinting at the screen for a while, my eyes just about managed to pick out the first few lines. Oh dear.

YOU ARE IN OFFICE.

THIS IS GOING TO BE ONE HELL OF A DAY. WITH ALL OF THESE PAPERWORKS TO DO. THERE WAS SOME KIND OF QUESTIONAIRE AS WELL. WHAT SHOULD I DO?

Spelling and grammar errors in the very first thing the player sees? Never a good idea. Not to mention the prose switching from present to past tense, then back to present again. What follows after that was some kind of questionnaire based on the Harry Potter books. (What does any of this have to do with being a detective? Beats me.) As I've never read the Harry Potter books, I guessed at the answers, got them wrong, and the game ended. But, determined to at least give the game a fair go, I restarted, got the 'questionaire' wrong again, tried a third time... and made it. Woo-hoo! Onto the game proper...

Or in theory anyway. Only there doesn't really seem to be a proper game here. The first room description I see after the questionnaire has finished simply reads YOU ARE IN LOUNGE. There's nothing else listed so presumably there's nothing in the lounge. Even exits. A few lines of badly written dialogue flash by on screen, at the end of which I'm given a couple of options in CYOA format to progress the game. If, that is, you can be bothered to play this game for much longer. I couldn't.

There are so many things wrong with The Detective that this review would probably be five times as long if I attempted to list them all. But in short: spelling mistakes; grammatical errors; terrible colour display (seriously, it's painful on the eyes); no kind of logic; no storyline; the location staying the same even when you've moved somewhere else (when you're in the location OUTSIDE FACILITY, you can jump in the back of a van and then climb into the front seat, and still you're said to be OUTSIDE FACILITY when you type look); and so on...

One best avoided.

1 out of 10



The Lazy Gun Cult by Felic Roman
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

There are times when playing The Lazy Gun Cult that I just felt like screaming. It's not the worst text adventure game I've every played, but it certainly misses out so many things that just about every other game I've ever played includes. Examples? There are doors that cannot be opened because the 'open' command hasn't been implemented. There's a door which I'm informed I can't open because it's locked, but – guess what? – the 'unlock' command hasn't been implemented. There's a button in another room. Now, what do you do when you find a button? You push it. Only not here apparently because the 'push' command hasn't been implemented. Are there are any basic commands Quest understands beyond compass directions and 'get', 'drop' and 'examine'? A few maybe, but good luck on finding them.

Still want to play the game after reading all that? Then read on...

You're a private investigator specialising in paranormal cases. You receive an anonymous call telling you to check out an old mansion where cult rituals are taking place. So, armed with not a single item at all, you set off to investigate it. And promptly find yourself locked in the mansion because, as sheer bad luck would have it, the door closed behind you and now you can't get out. (Probably not the worst introduction I've ever read but not much to write home about. Where's the depth? The setting of the scene? And am I expected to believe that my detective just decided to venture to this mansion in the middle of nowhere because a source told him there were cult rituals being enacted there?)

The Lazy Gun Cult wasn't quite as bad as some of the other Quest games I decided to review for the Non-Comp Review Project 2005, but it had so many things wrong with it that I'd be hard pressed to recommend it to anyone. Aside from the unimplemented commands, there are problems with the way items appeared in the room descriptions. You'll often see things like:

There is a small plinth pillar here.
a cask of oil

Or:

You can enter the venting tube system via a hole in the wall to your north, and an open trapdoor in the floor creates an exit down.
a bottle, a metal feather and A drawer in the desk.

Surely it wouldn't take a lot of effort to produce something better than "a bottle, a metal feather and a drawer in the desk"? I mean, this is a game I'm supposed to play and enjoy and the writer hasn't even bothered fixing the room descriptions so the items in it display properly.

While I didn't discover any hideous game-crashing bugs in The Lazy Gun Cult, I quickly found myself getting peeved off with it on the whole. The sheer amount of commands that should have worked but didn't made getting anywhere a struggle. There were the usual flaws that seem to bog down most Quest games – lack of background, remarkably poor standard of writing, typos, grammatical errors, items that can't be examined even when you're looking right at them – and in the end it wasn't a hard decision to give up playing and try something else instead.

2 out of 10



Operation: Sleepover by Justin Bailey
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

While unusual for a Quest game in that there were no hideous errors in it (at least in the bits that I saw), Operation: Sleepover wasn't much fun to play.

It starts with, of all things, your sister's fairy (or faery as it's spelt here) guardian showing up and telling you not to interrupt the sleepover she and her friends are having. To make sure you don't, she then magically locks the door to your bedroom. (Not a very good magical lock, as it happens, because examining a nearby book tells you how to get it open. Only don't try reading the book because the READ command isn't recognised...)

After that, you're free to explore a not very interesting house and do... not much really. Most of the rooms have descriptions that are little more than a line long and there's no sense of depth in any of the locations. A typical description:

You are in the Downstairs Hallway.

You can go south, east or west.

The laundry room is to the west, the party is to the east.

Or:

You are in the Bathroom.

There is a toilet, the bath tub and a mirror here.

You can go south.

While there's no need to have room descriptions that stretch for pages, a bit more than YOU ARE IN THE BATHROOM followed by a shopping list of what's in the bathroom would be nice.

While more technically accomplished than most Quest games I've played (i.e. no hideous errors, no crashes without warning), there's very little about Operation: Sleepover that I could find to recommend. There's not even much in the way of gameplay to get your teeth stuck into, and with no hints, and no real indication of what you're supposed to be doing, it wasn't long before I was yearning to try something else instead.

3 out of 10



Star Wars: Escape from Dagobah by David Leavitt
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

Ah, good old Star Wars. I was always a fan of the films as a kid but less enamoured with the newer ones. If a really great text adventure was 'A New Hope' or 'The Empire Strikes Back', then this one would firmly be in the territory of 'The Phantom Menace'. Which isn't to say that it's a terrible game by Quest standards. By Quest standards it's actually not bad. Judged by the standards of any other system, though...

The background is brief and to the point: you're delivering a cargo to the aid of Princess Leia but the freighter you're on crash lands on the surface of the planet Dagobah. As sheer good luck would have it, you have survived whereas everyone else died. Betcha didn't see that one coming.

Escape From Dagobah highlights some of the best and worst of Quest. On the positive side, the room descriptions are pretty decent. Nothing particularly special and unlikely to win awards for style, but adequate for the job in hand. On the negative side, the author hasn't taken the time to override the Quest default and so every room description you see has a few lines appended to it that have all the depth of a shopping list. Kinda kills the atmosphere. So you might have:

You are in Forest.

There is Sharp Rock here.

You can go north, south, west or up.

The trees are old, with rocks and shrubbery situated in an arranged pattern around the trunks. There is a tall sharp rock pointing to the air. Some trees look as though they can be climbed.

The actual description of the room isn't bad, but why oh why not override the default so it doesn't list YOU ARE IN FOREST right at the start? And Quest's annoying habit of capitalising item names doesn't help matters much either.

Elsewhere, the game's shortcomings are more apparent. One location advises me there are trees that can be climbed but the CLIMB command doesn't work. There are items that can clearly be read – a note from Yoda and a list of the crew – but READ doesn't work. There are items – a vine being one of them – that can't be picked up. There are enemies that can't be attacked – or at least KILL, ATTACK, SHOOT, FIGHT and HIT don't work.

Fifteen minutes into the game and I was aching to quit. Like I said at the start of this review, for a Quest game this isn't bad, but that still doesn't make it any good.

3 out of 10



Three Worlds by Zach Kelly
Platform: Quest
Download: Quest Site
Additional links: Quest Site discussion
Reviewed by David Whyld

Sometimes you play a game and you know – you just know – right from the very start that you're not going to like it. Three Worlds was one such game.

What's it about? Er... good question. There's no introduction at all. The game just starts with this wonderful description: YOU ARE IN EARTH. Ouch. The very first line in the game and already there's a grammatical error. Can it get any worse?

Oh yes.

Items are mentioned in the room descriptions of Three Worlds but they can seldom be examined. The first location lists "the Earth", "a magnificent stairway", "some clouds" and "a stairway of brimstone", but obviously these aren't considered important enough by the author to warrant even the most basic description.

Wandering around a little, I came across Heaven's Gate and St Peter. The Gate can't be opened – the program doesn't even understand the command! – and examining it merely informs me that if I use something as a lever I might be able to break the gates (that's 'gates' plural there whereas in fact there's only one gate mentioned previously). Elsewhere I found a golden sword just lying on the ground which, remarkably enough, was still listed in the room description even after I'd taken it and dropped it in another location. If all of that wasn't bad enough, and it was, the layout of the game is seriously messed up. Going south then north doesn't always lead you back to the same location. That might be deliberate but something tells me it was more likely as a result of careless programming.

By this stage, it was pretty obvious that Three Worlds wasn't going to be a game that I was likely to enjoy. So when I died a minute or so later – killed by Satan himself (complete with a terrible piece of spoken dialogue which repeated itself for no good reason) – I was ready to quit anyway. Incidentally, the game crashed when I died and I had to exit out of the programme to try it again.

All in all, Three Worlds is one of the worst games I've ever played and if this is anything of an indication of the overall quality of the games written with Quest, then it's poor reputation is well deserved.

1 out of 10

Wow - a few 4/10's!1

To be honest I wish I had the time to even think about programming in general - but I hardly have time to even listen to music!

I know if I got a game in there that it'd get around a 4/10 at least. Most that are using Quest just don't want to fuss about anything though and just churn out bad games.

Some interesting points raised there, but I think I ought to clear up a few misconceptions.

A lot of the supposed flaws in the system are in fact flaws in the games themselves. Quest provides plenty of functionality for making good games, but as you can see by the poor standard of spelling and grammar in many of the games, very often authors don't take sufficient care to make their games work well.

For example, while generally it is certainly true that "it is not very rewarding to spend much time using non-standard verbs in Quest games", that doesn't mean that Quest doesn't provide functionality to let authors add appropriate verbs. A game that allows "open door" but fails to recognise "open jar" as even using a valid verb is simply poorly written - it is certainly easy enough to get Quest to recognise "open" generically and provide an appropriate response if something isn't openable.

Likewise, displaying the introduction every time you restore from a saved game is simply poor game design. When initialising, a well-designed game should check whether it is being launched afresh or from a saved game, and display any introductory text only when appropriate. This is not at all difficult to do.

To clear up one final point, Quest is designed with accessibility in mind, which is why it does in fact provide options for overriding all text formatting. If you can't read (or just don't like) a particular colour scheme, go to the Options window and select "Don't allow games to change foreground and background colours".

I can accept that a lot of the errors with Quest are actually errors on behalf of the game writers; i.e. simply being too lazy to implement all the verbs they should be doing. But Quest really needs to have more verbs implemented by default, to save all the lazy writers from having to implement them themselves. It also needs to bring itself in line with all the other text adventure systems and at the very least: up arrow to repeat the previous command, a functioning UNDO command.

BTW I tried the font and colour settings and couldn't get it to work in the one game that really needed the font and colour settings changed (The Last Detective). But I managed to get it to work fine in another game. Is it possible to specify in a game to prevent the player from overriding the colours?

Strange - it works for me, and The Last Detective is the game I just tested it on. If you set the option after loading the game, the background goes white (or whatever your default is) but the already-printed text stays red. Subsequent text is printed in black (or, again, whatever your default foreground colour is).

There's no way for a game to override the player's override option - you could end up with a long options window if you went down that route.

[X] Don't allow games to change foreground and background colours
[X] Not even if they override my own personal choice
[X] Not even if they ask really nicely
[X] I really, really, really don't want them to change the colours even if the game thinks it's amazingly important and wants to disregard all my other options telling it I don't want the colours changed

Game reviews don't necessarily have anything to do with the underlying system. Quest is full of functionality and more importantly - customization opportunities. The games can only be as good as their authors.

I suppose that's the obvious problem. 99% of the games written with Quest seem to be the kind of things that their authors threw together in the space of five minutes and uploaded a minute after that. Maybe it's because there's so little feedback around that people just don't realise how bad their games are, or simply that what bit of feedback there is is completely misguiding. I've seen so many glowing 'reviews' on the Quest games page for games that are practically unplayable that it makes my head ache. I'm sure a good number are simply down to the game's author logging on under half a dozen different names and posting positive comments about his game simply to give the impression that it's actually worth playing, but there also seem to be an alarming number of people who actually think the games are good. And then there are those who just tend to assign 4 or 5 star ratings to every game they play whether it's any good or not.

Which of course isn't a clever idea as every time someone from outside the Quest community heads along here and decides to play a game, they probably end up picking one that has lots of positive reviews and high ratings... and then they play the game, realise it for the piece of tosh it is, and head off into the sunset again probably not realising there are better games around.

I posted this on RAIF, but you didn't respond:

> For example, while generally it is certainly true that "it is not very rewardi
> to spend much time using non-standard verbs in Quest games", that doesn't mean
> that Quest doesn't provide functionality to let authors add appropriate verbs.
> game that allows "open door" but fails to recognise "open jar" as even using a
> valid verb is simply poorly written - it is certainly easy enough to get Quest
> to recognise "open" generically and provide an appropriate response if somethi
> isn't openable.

Why is the default behavior:
- OPEN (object with override): gives particular override
- OPEN (anything else): gives fallthrough
?

(For comparison, the usual behavior in Inform is
- OPEN (object with override): gives that particular override
- OPEN (object in scope without override): gives "That's not something
you can open."
- OPEN (gibberish, or object not in scope): gives "You can't see any
such thing."
)



> Likewise, displaying the introduction every time you restore from a saved game
> is simply poor game design. When initialising, a well-designed game should che
> whether it is being launched afresh or from a saved game, and display any
> introductory text only when appropriate. This is not at all difficult to do.

How exactly does initialization work, or why does Quest have these two
functions placed into one routine?

A function which is called when a new game is started is definitely
useful. A function called when upon a restore much less so. (I know a
few games have reshuffled information puzzles after a restore to avoid
brute forcing the puzzles, and did Floyd say anything after a restore?)
But I can't see any likely situation where I'd want to do an action in
both those cases; putting them together in an area which is likely to be
used seems like inviting the writer to shoot himself in the foot.

Are there any particular guides (like Roger Firth's Inform FAQ) that
discuss common pitfalls and how to avoid them?

You could possibly want the same function to happen at loadtime or new game start.
Wanting to place certain objects in certain locations for instance. Resetting the time of day - printing a simple message to the screen - setting up certain scoring mechanisms - making sure certain rooms are around/not depending on your desire.

It's extremely easy to tell if the game was loaded or not - but that's not what that area of the game is for.. It's for "when the game is started", not loaded/new-game.

As for your your comparison to inform - that is only because the system has a default number of verbs/actions/whatever built in. You can easily create a list of actions (possibly one big general rule to cover multiple actions) that would give fall-throughs... It's just that it doesn't exists yet.
Quest will work basically the same as - if not more complex - than the default inform behaviour:
For example:

global overide: You can open this object / can't open this object
global out-of-scope: This object is not here - silly!
room override: don't be silly, opening anything in this room would be impossible due to the inter-dimensional, quasi-directional gravitational forces!
room out-of-scope: Thank god the object isn't here, Jay the security guard wouldn't have liked that!
everything else Which would be what exactly? a mis-spelling of open I guess, which would give the standard "not aware of how to do that" sort of reply.

Tr0n wrote:You could possibly want the same function to happen at loadtime or new game start.
Wanting to place certain objects in certain locations for instance. Resetting the time of day - printing a simple message to the screen - setting up certain scoring mechanisms - making sure certain rooms are around/not depending on your desire.

It's extremely easy to tell if the game was loaded or not - but that's not what that area of the game is for.. It's for "when the game is started", not loaded/new-game.

Why would you want those actions to specifically happen after a restore? Wouldn't they be saved with a normal save? And do you benefit that much from having the two functions be one?
How many times have you found something that would be better handled as:

sub StartGame {
  // set up scoring
  ...
}

instead of

sub OnStart {
  shared_code();
}
sub OnRestore {
  shared_code();
}
sub shared_code {
  // set up scoring mechanisms
  ...
}

Now, how many Quest games would benefit from being

sub OnStart {
  // print init message ...
}

instead of

sub StartGame {
  if (! restoring_game) {
    // print init message
    ...
  }
}

As for your your comparison to inform - that is only because the system has a default number of verbs/actions/whatever built in. You can easily create a list of actions (possibly one big general rule to cover multiple actions) that would give fall-throughs... It's just that it doesn't exists yet.
Quest will work basically the same as - if not more complex - than the default inform behaviour:
For example:

global overide: You can open this object / can't open this object
global out-of-scope: This object is not here - silly!
room override: don't be silly, opening anything in this room would be impossible due to the inter-dimensional, quasi-directional gravitational forces!
room out-of-scope: Thank god the object isn't here, Jay the security guard wouldn't have liked that!
everything else Which would be what exactly? a mis-spelling of open I guess, which would give the standard "not aware of how to do that" sort of reply.

And these are hardly difficult to get in Inform: (going by memory, so these may not be exact)

Object unopenable "Unopenable Can" 
 with name 'unopenable' 'can',
      before [ ; Open: "You can't open this object."; ];

Object no_open_room
 with before [ ; Open: "Don't be silly..."; ];

Object jays_room
 with before [ ; OpenOOS: "Thank god the object isn't here ..."; ];

[ OpenOOSSub; print_ret (The) noun, " ", IsOrAre(noun), " not here, silly."; ];

[ OpenNonsenseSub; "Open what?"; ];

Extend 'open'
  * scope=AnyObject -> OpenOOS
  * topic -> OpenNonsense;

(with AnyObject from a DM example).

I see no gains in flexibility in the Quest method; but I do see a lot of extra work needed in the parts of the program which should be straightforward.

Freak wrote:I see no gains in flexibility in the Quest method; but I do see a lot of extra work needed in the parts of the program which should be straightforward.

I think you've pretty much hit the nail on the head there: Quest can do what a lot of other systems do, but only with a lot more effort.

Speaking from the GUI side of things, which is the only aspect of Quest I've ever really spent any time with, it seems very poorly designed. Nothing is easy to do, everything is complicated and unnecessarily longwinded. The interface needs a redesign to make it easier and quicker and use, and Quest is never likely to produce any games of decent quality until that redesign happens.

Why would you want those actions to specifically happen after a restore? Wouldn't they be saved with a normal save? And do you benefit that much from having the two functions be one?

That would depend on why you wanted it to go off at the start and on load. I described multiple reasons why someone might - a 'reset' of certain variables is just one of them.

Personally I prefer looking at one function for the 'start' - instead of two places, and then off to another for anything common.

Now, how many Quest games would benefit from being

That's not what I'm saying. That if is just so simple to do - yet idiots just don't use it.

And these are hardly difficult to get in Inform

I'm not saying they're difficult in inform.
But they're hardly difficult in Quest! You can do it with about 3 if's, and two global commands (then using object properties - as it looks like you do there) if my brain isn't totally liquid.

OK, now let me ask you - what order of presidence does you object properties take? You've got object's with different "open" properties than rooms (Open: and OpenOOS: ... Not sure what the OOS means) - does the room over-load the object? If so - why? Maybe I want the object over the room.. or the game over the room - or the game over the object - and then the room.. I don't want that decided for me!

That inform you posted doesn't make total sense to me. Must be because I partly know C++, but again - I don't want something giving me a 'default' action... I think that's the whole basis behind C++, seeing as how they remove EVERY built-in accessory you can find in java/VB/whatever.

but I do see a lot of extra work needed in the parts of the program which should be straightforward.

I don't. I see it as a blank sheet of paper in which *I* can do things how I want - instead of having it done how I don't want it.

Tr0n wrote:

Why would you want those actions to specifically happen after a restore? Wouldn't they be saved with a normal save? And do you benefit that much from having the two functions be one?

That would depend on why you wanted it to go off at the start and on load. I described multiple reasons why someone might - a 'reset' of certain variables is just one of them.

Personally I prefer looking at one function for the 'start' - instead of two places, and then off to another for anything common.

Could you please be specific about exactly WHY such code would have to be called both on starting new game and on a restore, or, more specifically, why having it called on only one of those occasions wouldn't work. Seriously, I don't understand what you're suggesting.

[quote]Now, how many Quest games would benefit from being

That's not what I'm saying. That if is just so simple to do - yet idiots just don't use it.[/quote]

Sure, it's easy IF you realize that the code will be called both on a new game or a restore and IF you know what variable to check.

[quote]And these are hardly difficult to get in Inform

I'm not saying they're difficult in inform.
But they're hardly difficult in Quest! You can do it with about 3 if's, and two global commands (then using object properties - as it looks like you do there) if my brain isn't totally liquid.

OK, now let me ask you - what order of presidence does you object properties take? You've got object's with different "open" properties than rooms (Open: and OpenOOS: ... Not sure what the OOS means) - does the room over-load the object? If so - why? Maybe I want the object over the room.. or the game over the room - or the game over the object - and then the room.. I don't want that decided for me![/quote]

(from grammar.h)
Verb 'open' 'uncover' 'undo' 'unwrap'
* noun -> Open
* noun 'with' held -> Unlock;
(from my code)
Extend 'open'
* scope=AnyObject -> OpenOOS
* topic -> OpenNonsense;

So: Open ... will attempt to:
match the rest of the line with a noun currently in scope, then generate an <<Open thatnoun>> action.
match ... with a noun in scope, the word with, and noun currently held, then generate an <<Unlock firstnoun secondnoun>> action.
match ... with a noun, then generate an <<OpenOOS thatnoun>> action.
(OpenOOS stands for open out of scope; it's a new action I defined; similarly with OpenNonsense.)
finally, it will match anything for the rest of the line and generate an <<OpenNonsense>> action.

That inform you posted doesn't make total sense to me. Must be because I partly know C++, but again - I don't want something giving me a 'default' action... I think that's the whole basis behind C++, seeing as how they remove EVERY built-in accessory you can find in java/VB/whatever.

Default behavior is:
Call GamePreRoutines. If it returns true, stop.
Call orders on player. If it returns true, stop.
Call before on the current location. If it returns true, stop.
Call react_before on each object in scope. If any returns true, stop.
Call before on the noun. If it returns true, stop.
Call the appropriate ...Sub routine. (For an Open action, call OpenSub.)

If I need to change the order, or add any additional levels, I replace BeforeRoutines() with whatever is necessary.

[quote]but I do see a lot of extra work needed in the parts of the program which should be straightforward.

I don't. I see it as a blank sheet of paper in which *I* can do things how I want - instead of having it done how I don't want it.[/quote]

And in Inform I can do things as I want, except I don't have to do the uninteresting things again and again.
Graham Nelson didn't specifically plan for an in-game Scheme machine (Lists and Lists), or a divided room (Shade), or connectable objects (Spider and Web) while designing Inform, but Plotkin was able to rewrite the library to implement those. Is Quest up to handling any of those?

Could you please be specific about exactly WHY such code would have to be called both on starting new game and on a restore

Not really. I don't have much use for anything on game restore in most cases.

You may wish a date/time entry code - to perhaps have real-in-game time. This would need to be entered both at game-start, and everytime the game loads. How about a discussion-bot which would like you to input the day - then the mood you're in, etc.
These don't work on one of them because mood changes/time changes... If you want to have a random thing, or a part of the game to be reset apon game-load (I wouldn't know why - that's up to the maker to decide).

Can you give me any 'specific's on why you'd want to run on game restore?

Sure, it's easy IF you realize that the code will be called both on a new game or a restore and IF you know what variable to check.

Isn't that the same with EVERYTHING?
That isn't an argument - only an excuse to be lazy.
It is documented in the Quest documentation - and at the same point, the IF is explained too!

Verb 'open' 'uncover' 'undo' 'unwrap'
* noun -> Open
* noun 'with' held -> Unlock;
(from my code)
Extend 'open'
* scope=AnyObject -> OpenOOS
* topic -> OpenNonsense;

Sure, it's easy IF you understand the inform language.. And know (and invent, as you later actually say) some parts (OpemOOS and OpenNonsense so you said).

So: Open ... will attempt to:
match the rest of the line with a noun currently in scope, then generate an <<Open thatnoun>> action.
match ... with a noun in scope, the word with, and noun currently held, then generate an <<Unlock firstnoun secondnoun>> action.
match ... with a noun, then generate an <<OpenOOS thatnoun>> action.
(OpenOOS stands for open out of scope; it's a new action I defined; similarly with OpenNonsense.)
finally, it will match anything for the rest of the line and generate an <<OpenNonsense>> action.

But you don't answer my question.
You go through all the longwinded way inform digests the sentance into nouns/etc, then throws that against it's list of verbs, and then goes for OpenOSS or OpenNonsense.
BUT if you have OpenOSS defined Globally, in the current room, AND in the object - which takes presidence? The object, room or game? I suppose you can write your own presidence code though.

And in Inform I can do things as I want, except I don't have to do the uninteresting things again and again.

I believe they're called functions..

in-game Scheme machine (Lists and Lists)

Don't know what this is...
You can make a simple *list* script quite easily IMO. Depends on what you expect from a list.

or a divided room (Shade)

Yeah, you can implement this if you wish... Would be a bit like the grid system that I've seen others working on in Quest, only per-room.

connectable objects (Spider and Web)

How do you mean this? Do you mean that they are two seperate objects which can be 'melded' together? .. In that case then yes/no.
In any language I know you cannot 'combine' two objects - but instead you have to link them. This is entirely possible using at least two different ways.

None of these have been 'written' out though..

I think, using Al's typelib (the only general library to be included with Quest), that open is handled much more respectfully - along with many other actions - including lock/etc.
I personally don't use it - but you can't compare inform, with a library - to Quest, without a library.

Tr0n wrote:

Could you please be specific about exactly WHY such code would have to be called both on starting new game and on a restore

Not really. I don't have much use for anything on game restore in most cases.

You may wish a date/time entry code - to perhaps have real-in-game time. This would need to be entered both at game-start, and everytime the game loads. How about a discussion-bot which would like you to input the day - then the mood you're in, etc.
These don't work on one of them because mood changes/time changes... If you want to have a random thing, or a part of the game to be reset apon game-load (I wouldn't know why - that's up to the maker to decide).

Can you give me any 'specific's on why you'd want to run on game restore?

No, I can't give you any specifics. I haven't the faintest idea why anybody would want to do so, and I've been asking you.

I tend to follow such rules as Larry Wall's "Easy things should be easy; hard things should be possible." and prioritizing (Making common tasks easy is more valuable than making a rare task easy. Making a simple task easy is more valuable than making a complex task easy. Making an unwanted behavior easy to do by accident is NOT good. Requring the user to look up obscure features for the purpose of a rare or tricky task is more acceptable than requiring the user to look up obscure features for a simple or common task.) or the principle of least astonishment (The best behavior is that which will astonish the user least.)

1) Running actions at the beginning of a game is a simple, common task. Almost every game uses it.
2) Running actions on restore, or on both restore and beginning a game is a tricky, rare task. Almost no games (You've kept saying that somebody might want this feature, but you've never pointed to any games that actually do so.) use this. But suppose 5% of all games use it.

Using (Single Function) over (Two Separate Functions):
a) Makes it X amount easier to run the same code on both new game and restore.
b) Makes it X amount harder to run code only on new game.
c) Makes it easier to get the unwanted behavior of running code that's supposed to be run on new game only also run on restore.

a gives you X amount of benefit 5% of the time.
b gives you X amount of cost 95% of the time.
Together, a and b are a net loss.
c is always a loss.

Having separate functions for new game and game restore is the better option. PERIOD.

[quote]Sure, it's easy IF you realize that the code will be called both on a new game or a restore and IF you know what variable to check.

Isn't that the same with EVERYTHING?
That isn't an argument - only an excuse to be lazy.
It is documented in the Quest documentation - and at the same point, the IF is explained too!

Verb 'open' 'uncover' 'undo' 'unwrap'
* noun -> Open
* noun 'with' held -> Unlock;
(from my code)
Extend 'open'
* scope=AnyObject -> OpenOOS
* topic -> OpenNonsense;

Sure, it's easy IF you understand the inform language.. And know (and invent, as you later actually say) some parts (OpemOOS and OpenNonsense so you said).

So: Open ... will attempt to:
match the rest of the line with a noun currently in scope, then generate an <<Open thatnoun>> action.
match ... with a noun in scope, the word with, and noun currently held, then generate an <<Unlock firstnoun secondnoun>> action.
match ... with a noun, then generate an <<OpenOOS thatnoun>> action.
(OpenOOS stands for open out of scope; it's a new action I defined; similarly with OpenNonsense.)
finally, it will match anything for the rest of the line and generate an <<OpenNonsense>> action.

But you don't answer my question.
You go through all the longwinded way inform digests the sentance into nouns/etc, then throws that against it's list of verbs, and then goes for OpenOSS or OpenNonsense.
BUT if you have OpenOSS defined Globally, in the current room, AND in the object - which takes presidence? The object, room or game? I suppose you can write your own presidence code though.[/quote]

As I mentioned in the post, default precedence is GamePreRoutines, player.orders, room.before, obj.react_before (for each object in scope), noun.before, ...Sub. Or, for your particular question, first room, then object, last game.

Having overrides to the case when an object is out of scope is uncommon, so it's not as important that it be easy. (And, for comparison, how much effort is needed to get the same effect in Quest?)

[quote]And in Inform I can do things as I want, except I don't have to do the uninteresting things again and again.

I believe they're called functions..[/quote]

Sorry; by interesting / uninteresting, I mean "particular to my game" / "common to games in general". For example, "if the player drinks the green potion, he gains five points of strength" is particular to my game; "trying to open an unopenable object gives the message 'That's not openable.', while trying to open an object not present gives the message 'You see no such thing, and when the bag is open, the player can see what's inside but when it's closed he can't.'" is not.

[quote]in-game Scheme machine (Lists and Lists)

Don't know what this is...
You can make a simple *list* script quite easily IMO. Depends on what you expect from a list.

or a divided room (Shade)

Yeah, you can implement this if you wish... Would be a bit like the grid system that I've seen others working on in Quest, only per-room.

connectable objects (Spider and Web)

How do you mean this? Do you mean that they are two seperate objects which can be 'melded' together? .. In that case then yes/no.
In any language I know you cannot 'combine' two objects - but instead you have to link them. This is entirely possible using at least two different ways.

None of these have been 'written' out though..
[/quote]

http://mirror.ifarchive.org/if-archive/ ... /Tangle.z5
http://mirror.ifarchive.org/if-archive/ ... e/lists.z5
http://mirror.ifarchive.org/if-archive/ ... e/shade.z5

or the namable cubes from Spellbreaker or Balances. Or most of Museum of Inform.

You've gone on about Quest's special flexibility. Personally, I think that Inform is better at making the simple things simple, and at least as good at making the hard things possible. So please point me to some Quest games which need its special flexibility.

I think, using Al's typelib (the only general library to be included with Quest), that open is handled much more respectfully - along with many other actions - including lock/etc.
I personally don't use it - but you can't compare inform, with a library - to Quest, without a library.

Why not? I compare the two systems as they have been used. Comparing system A in the standard configuration against B in its minimal configuration when that differs from its standard config, is unfair. But comparing A's standard config to B's minimal config because B lacks any standard config is perfectly fair. If Graham Nelson went to a lot of work to save me the effort of doing common tasks and Alex Warren did not, that is to Inform's benefit.

Having separate functions for new game and game restore is the better option. PERIOD.

You're looking for benefits/etc.
I don't know if I did say 'it was better this way'.. I did a quick scan of my previous posts and didn't see anything to that effect... I personally go for the more 'simple' aproach, getting it working and as 'simple' as possible.
Personally I think one function called at start/load is simple.

It could be really easy for Alex to alter that - adding in two functions called "gamestart" and "gameload"... keeping "startscript" for backwards compatibility..
I suppose that's something to add to the list (I suggest emailing him to make sure he reads it - incase he doesn't read this).

Having overrides to the case when an object is out of scope is uncommon, so it's not as important that it be easy. (And, for comparison, how much effort is needed to get the same effect in Quest?)

The default is global, over-ridden with room commands. You may make a command to take any priority you wish.
So it's as much effort as you're willing to put into a project. Isn't too much though - as I said, a couple of if's.

Sorry; by interesting / uninteresting, I mean "particular to my game" / "common to games in general". For example, "if the player drinks the green potion, he gains five points of strength" is particular to my game; "trying to open an unopenable object gives the message 'That's not openable.', while trying to open an object not present gives the message 'You see no such thing, and when the bag is open, the player can see what's inside but when it's closed he can't.'" is not.

That functionality is provided by Al's typelib library.
Those that do not use it are to blame - not the system.

None of these have been 'written' out though..

Sorry - I meant "not coded in quest".

You've gone on about Quest's special flexibility

I don't think I've posted "flexibility" once (did a search of the posts - only found you saying it). I have given the impression it gives you freedom and doesn't get in your way at all - or at least tried to.
As I've said, it's a blank sheet that requires you to mold it into a game..

Why not? I compare the two systems as they have been used.

Because comparing how the two systems are used - and then judging the system on that basis is totally rubbish!
You may as well say that the N64 was nothing and the PSX (playstation) was the best game-console of the two, based purely on the fact of number of games, or games that *I* liked on either console.
That isn't true, seeing as how the N64 was the more powerful, (although the cartridge system was it's downfall IMO).

If Graham Nelson went to a lot of work to save me the effort of doing common tasks and Alex Warren did not, that is to Inform's benefit

I agree - to some extent. Effort is the main problem here. Game-makers (I use the term lightly) with vague idea's, little enthusiasm and little determination come here and create a 5-minute wonder, then upload their games (which is amazing seeing as how they have no skill in computers at such a young age) to the web.

You're trying to attack the system - which I can see no error in.
I can only see a lack of effort in building up the foundations - which I can be partly blamed for. I could have created nice command libraries etc, but haven't.
I shall get right onto it after every other issue in my life has resolved itself, and I'm able to actually spend some time programming instead of everything else (including arguing over null points on a discussion board ).

Tr0n wrote:I agree - to some extent. Effort is the main problem here. Game-makers (I use the term lightly) with vague idea's, little enthusiasm and little determination come here and create a 5-minute wonder, then upload their games (which is amazing seeing as how they have no skill in computers at such a young age) to the web.

I think that some of the problem there lies in the fact that Quest is marketed as a tool that is "really easy to use" in making text adventures, which is misleading to say the least. Compared to the only other text adventure tool out there that has a GUI - Adrift - it's mind boggingly complicated. I suppose what happens if Clueless Bob hears all this stuff about how easy Quest is, poddles over in his ignorance to try it out, and finds out that the GUI is so darn confusing he can't make head or tail of it. The coding side of things just goes so far over his head he probably can't even see it. But not wanting to waste the 15 minutes he's spent using Quest so far, he finishes off the "game" he's working on, uploads it and promptly departs. Another steaming pile of tripe added to Quest's ever lengthening archive of awful games.

Maybe the focus of Quest should change, if the program itself isn't going to (and it shows little indication of doing so). Rather than marketing it as a text adventure tool for people with no programming experience, market it as a tool for programmers. See if you can actually encourage some of the people out there who know a thing or two about game writing to give it a try.

And the biggest problem with Quest? Its resignation fee. Scrap it. Unless a system has a wide user base or a large quantity of quality games (both of which Quest lacks), you're never going to encourage many people to buy it.

That is only for the benefit of hiding your code. David.

I also agree that thing's are marketed toward the "really easy to use" market. You find alot of places doing this (if you look in the right places) and you also find VERY poor results made from these products.

Take Visual Basic/dark basic/2D demo scroller makers/game maker pro 2000. These types of things really produce some of the worst items out there, although they do ease the people who have ambision into the area quite well.

I would like to know in what sort of ways you'd like to improve the gui.

How to improve the GUI? Make it easier to use. Do away with the necessity to have to perform half a dozen different actions just for the sake of adding a simple command to the game. Do away with the multiple pop up windows every time you're editing an item or custom command - do you really need twenty different windows open all over the screen that then have to be closed when you're finished with the editing? Install some much needed user shortcuts.

Pretty much whatever else I said the last fifty times the subject was raised.


As I said before, and I'll probably say again, no one will ever take Quest seriously until someone goes ahead and writes a great game with it. And no one will ever go ahead and write a great game with it in its current state.

You mean QDK..
Yeah, I do have to agree. A tree-list would be much more appropriate for the situation I reckon.

I do agree QDK is a bit of a state.

I've always been kind of curious what Alex's take on the GUI and improving it is, but he never seems to take part in any discussions about it, and as it's remained essentially the same throughout all the releases of Quest that I've used, it's probably not going to get a major overhaul any time soon.

<dons his biohazard suit and combat helmet>


Now this is what I like to see... a close knit family.


Today I discovered Davidw. A harsh critic, but not one without valid points.

As painful as some of Davids words are, as an aspiring new QDK/ASL author, I appreciate hearing the good, the bad, and the ugly. It helps me to understand where the difficulties, traps, and pitfalls are.


I had already determined that there is a wide range of skill and education to be found with the users of this forum by reading the forums themselves. I had assumed that the same would be true of games written as well.

Concise, constructive suggestions of improvements are (imo) more likely to acheive positive results. But thats just me. And what do I know? I'm the noob of the week.

Bit of advice: if you're new to the world of interactive fiction and want people to like any games you write, you're in the wrong place.

If you fancy the GUI side of things, go with Adrift. If you fancy yourself as a coder, go with Tads or Inform.

If, on the other hand, you desire to write games with the most poorly regarded system out of them all, go with Quest. You can be guaranteed that people will take one look at your game, think "oh god another buggy Quest game" and promptly try something else. Right now, I'd say Quest is the worst possible choice for writing a game with and it's likely to remain that way for the foreseeable future unless it gets a major overhaul.

So David, why is it that you hang out here? Just to spew negativity? What good does it do for you to tear down on other peoples efforts? Other than maybe getting some sick pleasure of just ripping into people to make yourself feel superior? Is that it?

I've learned some things from your comments. They are informative. But the negativity and hostility attached to them seems rather personal.

Also, being new here, and just recently getting reinterested in the IF thing... I will go and look into these other systems you mention. But even if they *are* better... why stay here and tear down at other peoples efforts.

Again constructive critisism is so much more efficient that constant flaming. Also, could you point me to a link of some of your own work? So that I can see for myself how much better you can do?


Thank you.


[addendum 1] Adrifts installer requires the replacement of unspecified system files. Not going to happen. Adrift is out before it ever got installed.

Why do I hang round here? I wonder that myself sometimes.

I checked out several different systems before settling on Adrift, Quest being one of them. At the time, I felt it had potential. It had, in theory, more power than Adrift yet was harder and more time consuming to use. Anything I could do in Quest, I could also do in Adrift and much more easily besides. So I just registered on the forum and decided to sit back and wait for it to improve. Three years later I'm still waiting. And while Quest might once have seemed to have potential, it doesn’t any longer. Of course, it could be that the next version of Quest is about to be unleashed on us and, lo and behold, it'll be everything it needs to be. But I kind of doubt it. I've seen several different versions of Quest since I first came across it and none of them have addressed the inherent problem with the system: it’s too confusing to use. No one in their right mind is going to use Quest if there are alternatives. And there are alternatives. Every one of them being better and more respected.

As for my own games? There's a link to my website in my sig. Check out “Back To Life… Unfortunately”, “Paint!!!”, “Second Chance”, “A Spot Of Bother”, “Shards Of Memory”… all seem to be reasonably popular.

BTW if you're going to dismiss Adrift because it installs some files on your system, you're doing yourself a disservice. I'm not going to claim Adrift is perfect – it isn't – but it’s light years ahead of Quest both in terms of how easy to use it is and the way it’s perceived by the rest of the IF community. I can give you the names of a dozen Adrift games that have got positive reviews from the rest of the community; can anyone here give me the name of even one Quest game?

But if you want go ahead and write games with Quest, you go for it. Your decision.

All right. I loaded Adrift on a test PC, I am wary of installing anything that tells me it wants to replace system files but does not tell me what specifically it is replacing.

To be forthright - David - it appears you are correct. At least after a cursory look and as far as the GUI goes. And as a beginner in the authoring of IF, that is one of my primary concerns. Ease of use. So pat yourself on the back.

Thats not to say that I will abandon Quest... I am going to continue to look into it. And Adrift. It may come to pass that once I am at a level that I am bypassing the GUI and just doing straight coding that things shift. I don't know. I'm not there yet. Not even close.

I CAN say that I have found Al to be very helpful here, and also Tron, and Ex seem to be willing to answer any questions. Alex, I haven't had any direct dealings with as of yet. Friendly peers makes a difference. People willing to answer questions are more likely to get my respect than people that just sit around badmouthing everything. you should ad a 'David' character to your Paint!!! game. You'd fit right in.

I still haven't really figured out why you hang out at a place you so obviously dislike, but thats your issue, not mine. The fact that you are allowed to speak freely and not have your posts or your account removed speaks well for Alex and his crew.

Your posture on these forums makes it difficult to 'like' you. Though your information is good, and your reviews are honest, it's not so easy to respect your opinion when you go making recommendations for something else. I don't know if you have a personal interest in Adrift or not. But your attitude here sets a bad tone and made it much less likely that I would try your recomendations. Now I inderstand you may not give a rats rear if you are 'liked' or not, but if your goal is to get people to look at other alternatives, you might think about how you present yourself. Just food for thought.

You could always look at my negativity as either refreshing honesty or someone trying to steer you away from making the mistake of writing a game in a system that virtually no one uses and no one outside of the Quest community (which numbers a dozen active members at best) will ever play.

Of course, if you're determined then go ahead and write your game with Quest. But before you do that, you ought to check out a few things first for yourself about the current state of interactive fiction and maybe ask yourself this one question:

* How come Quest has been around for so long and yet has failed to produce a single game of note?

Either there's not a single talented game writer who has ever tried his hand at Quest (kind of hard to believe) or there's an inherent problem with the system itself. Pick whichever answer seems appropriate.

As for me having a vested interest in Adrift? No. I've been using it for 4 1/2 years and I've written a lot of games with it and I'd like it to do well, but I don't have any involvement in the design of Adrift and I don't benefit from it doing well or suffer if it does poorly.

As for Quest itself, I'd like it to improve. I'd like it to show its potential. I'd like for someone to actually come along and write a decent game with it... but I imagine I'll be waiting a long, long time for that to happen.