Not sure how many read the I F Newsgroups, but for those that don't I refer you to the topic titled 'Anyone knows any good Quest games'.

Quest gets a bit of a mauling.

Now I have to say that I think a lot of the criticism (that relating to the numerous bug-ridden 'games' that should never have been released - at least not without a lot more testing) is fair comment. What I don't agree with is that Quest itself is the problem.

"It's just too flawed, too poorly designed, too buggy..."

Don't agree. While a lot of the 'games' made with Quest certainly deserve that indictment (and worse to be honest) I do not think it is due to any inherent defect in Quest. The problem remains that anyone can go from zero knowlege to knocking out a 'game' in Quest that 'sort of works' in a few hours.

Now if you put a tyro produced 3 hr first effort out as a game - then it is surely going to suffer when compared to games made in other systems which have a much longer learning curve before one can produce anything that works as a game. it's a fairly safe bet that a game that took 100 + hours to write is going to be a considerably better and more polished product than one that was knocked up on one wet sunday afternoon when there was nothing on TV...

Anyone care to comment?

MaDbRiT

I wholeheartedly agree!

As we've discussed in other threads, the quality of a game is dependent upon the amount of time that went into it.

IMO - Worst offenders: Spelling, grammar, conversational style, unintended dead ends, to name a few. Next: Tricky (i.e. stupid) puzzles which are supposed to add to the gameplay, but only confuse the player.

Quest, like others, makes it easy to create a game. But that's like saying that owning a car makes it easy to drive. Both take time and effort to develop the skills required to do it well. Another requirement (in both) is the advice and opinions of others. When designing a game, we [hopefully] already know how the game is to be played. Don't stop there - get a friend that knows nothing about the game to play it through and see if he/she gets the same results. Ask them to be critical!

As I'm writing this, I am reminded of Colossal Cave. As far as I can remember, this is where it all started. At least on the version I played (COBOL on a Prime 50 Series computer), it was perfect! CC should be a "must play" for one who wishes to create quality text adventures.

90% of ____ games are crud. That's just Sturgeon's Law (paraphrased), and it's true for all systems. Everybody posting knows that. Systems aren't judged by the 90% crud; they are judged by the 10% that isn't crud.

Quest does not have as much power as the Tier 1 languages. Period.

Museum of Inform collects a series of demonstrations of what Inform can do. Try porting that to Quest and see how they compare.

Source: http://ifarchive.giga.or.at/if-archive/ ... Museum.inf
Older compiled version: http://ifarchive.giga.or.at/if-archive/ ... /Museum.z5

"It's just too flawed, too poorly designed, too buggy..."

I stand by that comment as my own experiences with Quest have shown it to be horribly buggy. The last time I used it, it was prone to crashing and often wouldn't re-open game files after crashes, forcing me to constantly rewrite. Several times I was forced to debug the code manually despite the fact that I had written it using the GUI. Flawed? Poorly designed? It lacks the power of any of the other systems (except maybe Adrift) and the ease of use of Inform or Adrift. Even when a decent Quest game comes along - Gathered in Darkness - it's hard to play it and not think how much better it would have been had it been written in TADS or Inform instead.

David wrote

I stand by that comment as my own experiences with Quest have shown it to be horribly buggy.

Well, if that is your experience with it, it's fair comment and I can only sympathise. I've not found Quest to be particularly 'crash prone' on any of my computers. As for code made via the GUI being iffy, well, I'm a textpad sort of guy so I really can't comment on that area much (other than to say the latest GUI seems a lot less messy than the previous incarnation).

I am intrigued that you group Inform with Adrift in ease of use. Inform 6 was never exactly easy to use and I find Inform 7 slow and frustrating (although the concept is quite brilliant, my instructions never seem to parse to the code I expect them to!)

how much better it would have been had it been written in TADS or Inform

Yes - assuming an author had the time and inclination to learn one of those two (relatively) heavyweight systems the result might well be somewhat better. Of course the extra time it would have taken to learn TADS could have been spent on making the Quest version better instead. Better enough to make a real difference? - tough call!

I still believe it is possible to write a perfectly good game in Quest. Maybe not a 'brilliant' one that pushes the limits of what I.F. can do, but a properly sorted and entertaining piece should be possible.

MaDbRiT

"I am intrigued that you group Inform with Adrift in ease of use. Inform 6 was never exactly easy to use and I find Inform 7 slow and frustrating (although the concept is quite brilliant, my instructions never seem to parse to the code I expect them to!)"

I should probably have clarified that for ease of use I meant Inform 7. I'm not a coder so 6 was just foreign to me most of the time. But yes, I find Inform 7, at least the basics, very easy to use. It's not as easy as Adrift, and it's certainly not 'natural language' the way its designers claim, but putting together a relatively straightforward game in 7 isn't hard at all.

"Yes - assuming an author had the time and inclination to learn one of those two (relatively) heavyweight systems the result might well be somewhat better."

As I said above, I'm not a coder so I don't really know how much harder it would be to learn TADS or Quest, but I do see tutorials galore around the internet for TADS. I see none for Quest. If I was going to learn one, which would I choose - the one with tutorials explaining the finer aspects of coding and the one which has a very good reputation or the one with no (or very few) tutorials and a terrible reputation?

"Of course the extra time it would have taken to learn TADS could have been spent on making the Quest version better instead. Better enough to make a real difference? - tough call!"

To be honest, you'd have to spend one heck of a long time improving your Quest version before it came close to the standards of a TADS game. Even then, you'd still be stuck having people play your game in the default Quest player which would put it way behind the TADS version anyway.

"I still believe it is possible to write a perfectly good game in Quest. Maybe not a 'brilliant' one that pushes the limits of what I.F. can do, but a properly sorted and entertaining piece should be possible."

I think I said something similar in my review of Gathered in Darkness. But - and here's the thing I never really understand - why settle for writing a game in one badly flawed system when you could write it in another far better system?

MaDbRiT:

Just so we can establish a common frame of reference, could you list some games (Quest and non-Quest) that you have played?

Also:

1) In Quest:
- A, B, and C are tests.
- Does "if A or B and C then ..." mean "if (A or B) and C then ..." or "if A or (B and C) then ..."?

2) In Quest, how do you test whether two variables are exactly equal?

Freak wrote

Just so we can establish a common frame of reference, could you list some games (Quest and non-Quest) that you have played?

As in`what is my base for comparisons?'

Well, I first played Adventure games way back before Inform existed, and back then even wrote a (rather poor) game myself in Sinclair Basic on my ZX81. I bought a lot of the 'classic' adventures to play on the various 8 bit micros, but as the commercial viability of I.F. waned, Infocom & Magnetic Scrolls disappeared and my I.F. source became the downloading of some of the entries to the annual I F competition. I admit I only download those entries that have instant appeal to me, and I don't always finish them - either because I lose interest or (more often) other demands on my time get in the way.

Quest wise, if you discount the 90% of possible downloads that require no more than a cursory glance to tell they are dross (and I'm being very kind there) there are not a lot of Quest games left and I have probably downloaded most of them. Notice I did not say 'played' most of them, David & I may not agree on everything, but it seems we both have a similar lack of patience when we encounter glaring faults that should have never got past even a minimal amount of play testing.

In Quest:
- A, B, and C are tests.
- Does "if A or B and C then ..." mean "if (A or B) and C then ..." or "if A or (B and C) then ..."?

'if A or B and C' would I think be regarded as ambiguous by Quest as you have to use parentheses around conditions. I've simplified the actual conditions slightly here, but this is essentially how Quest would require it

if ((has matches) or (has lighter)) and (has petrol) then {
do <startfire>
}

2) In Quest, how do you test whether two variables are exactly equal?

if (%A% = %B%) then { This will run if variables a & b are equal (for numeric variables)
if (#A# = #B#) then { This will run if variables a & b are equal (for string variables)

MaDbRiT

here's the thing I never really understand - why settle for writing a game in one badly flawed system when you could write it in another far better system?

Ease of Use. Why does anyone use ADRIFT when TADS exists? Because ADRIFT is a lot easier to use, especially for the non coder. Some people will claim anyone can learn TADS in no time at all, but frankly that's just wrong. Take a look at the TADS library, to use TADS effectively you really need to understand how it works and indeed have a working knowledge of object oriented programming, which for most people is surely a non-trivial thing to grasp.

MaDbRiT

But in what way is writing a game in Quest easier than writing a game in Inform 7? Granted, it's probably easier to code in Quest than in TADS but even myself, a non-programmer, managed to get to grips with Inform 7. However I look at it, I can't understand the reasons for people choosing Quest over any other system. If you're a coder, go with Inform or TADS; if not, go with Adrift. Put another way: what does Quest offer that the other systems don't?

My reasons for using Adrift for so many years were simply down to the fact that it was the only sensible choice for me. I wasn't a coder, I had little real desire to learn, but I *did* want to write IF. My choices were either Adrift or Quest. The first was easy to use, seemed reasonably stable and had produced some good games: the second was confusing, prone to crash and had nothing but bad games. Is it any wonder I picked Adrift?

MaDbRiT wrote:Freak wrote

Just so we can establish a common frame of reference, could you list some games (Quest and non-Quest) that you have played?

As in`what is my base for comparisons?'

Well, I first played Adventure games way back before Inform existed, and back then even wrote a (rather poor) game myself in Sinclair Basic on my ZX81. I bought a lot of the 'classic' adventures to play on the various 8 bit micros, but as the commercial viability of I.F. waned, Infocom & Magnetic Scrolls disappeared and my I.F. source became the downloading of some of the entries to the annual I F competition. I admit I only download those entries that have instant appeal to me, and I don't always finish them - either because I lose interest or (more often) other demands on my time get in the way.

Quest wise, if you discount the 90% of possible downloads that require no more than a cursory glance to tell they are dross (and I'm being very kind there) there are not a lot of Quest games left and I have probably downloaded most of them. Notice I did not say 'played' most of them, David & I may not agree on everything, but it seems we both have a similar lack of patience when we encounter glaring faults that should have never got past even a minimal amount of play testing.

Please give some names. Of the non-dross games, which Quest games have you played, and where would you rank them compared to the modern non-Quest games you've played?

In Quest:
- A, B, and C are tests.
- Does "if A or B and C then ..." mean "if (A or B) and C then ..." or "if A or (B and C) then ..."?

'if A or B and C' would I think be regarded as ambiguous by Quest as you have to use parentheses around conditions. I've simplified the actual conditions slightly here, but this is essentially how Quest would require it

if ((has matches) or (has lighter)) and (has petrol) then {
do <startfire>
}

What's the correct syntax for parenthesizing? I tried

command <make fire 2> if (got <matches> or got <lighter>) and got <petrol> then msg <There's no need to make a fire at present.> else msg <You can't make a fire.  You'd need a lighter or matches, plus some petrol.>

but Quest barfs when it tries to load that.

And that's not the question I asked. Yes, it's ambiguous, but how does Quest resolve that ambiguity by default?

2) In Quest, how do you test whether two variables are exactly equal?

if (%A% = %B%) then { This will run if variables a & b are equal (for numeric variables)
if (#A# = #B#) then { This will run if variables a & b are equal (for string variables)

MaDbRiT

Try again.

	command <test> {
		msg <Enter two strings to compare.>
		enter <var1>
		enter <var2>
		msg <Comparing "#var1#" to "#var2#".>
		if ( #var1# = #var2# ) then msg <They're equal!> else msg <They're not equal!>
	}

Result:

> test
Enter two strings to compare.
Comparing "x" to "x ".
They're equal!

They're not equal. One has a space at the end.

But in what way is writing a game in Quest easier than writing a game in Inform 7?

Quest is Adrift-like in the sense it has a GUI, and yet it still has the facility to code manually in a relatively simple scripting language like (say) Alan.

Inform 7 has moved Inform towards ADRIFT & Quest in ease of use, but there is still a gap.

F.W.I.W. I agree that for you ADRIFT was the obvious and better choice of system - most definitely so at the time you chose it. It seems you have now moved to Inform 7 and I'm sure that is a very good choice too.

Frankly, with my original posting I was hoping more of Quest's actual users would chime in and turn this topic into a discussion of 'how do we improve our games' - to get the output up to that potentially quite decent standard I harp on about, but it hasn't happened.

"You can lead a horse to water..." and all that .

I give up. As far as I am concerned, this topic is dead.

MaDbRiT

Now where did I put that TADS 3 Manual...

The last thing Al just wrote resonates with me concerning quest verses Adrift. I tried both when I first got started. I'm not a programmer, but my vision for my game ended up being something I needed programming for. Quest simply allowed me the flexibility to start venturing into that territory on an instant gratification process. Now at this point, Im caught in two conflicting goals...

1) Now that quest has gotten me interested in programming, I can rewrite my entire game in something better and more efficient; Something that doesn't use up as much space and is more organized, etc. Something that even breaks less...

2) I can just finish my game in quest, now that Im waist deep in it, and still have fun playing and testing, and knowing that for users, I just have to make it seem clean and user friendly.

ADRIFT is limited as far as programmability goes, but it has a good standard library and a fairly shallow learning curve, and there have been a number of good games written with it. ("Goldilocks is a FOX!", "The PK Girl", and "Back to Life, Unfortunately" to name three.)

.asl is kind of similar to .t or .inf, except inconsistent and very limited, and QDK is ultimately a thin wrapper on top of .asl.

So, until the fundamental problems with .asl are fixed (and that's not going to happen unless it gets a complete rewrite), Quest's reputation isn't going to improve.

Or try porting some good games to Quest and comparing the result to the original. That'll control all the factors of game quality (such as writing quality or puzzle design) except those related to Quest.