I am a complete novice at this sort of thing so would really love some answers:

1. Just how easy is it for a complete novice to use this software?
2. Does it come with a data file of pre-understood words (get, drop, take etc) and can these be edited?
3. Once a game has been completed, how easy is it for others to play this game, would they need the axe software downloaded to run the game or can it run by itself?

Cooper

Hi Cooper, and welcome to the Quest forums

To answer your questions, one by one:

1. Just how easy is it for a complete novice to use this software?

It's exceptionally easy to 'knock out' a simple game in Quest. This is both a good and a bad thing. The good side is that there is near instant gratification, one can make something that works (after a fashion) in a couple of hours. The bad side is the fact you can make something that works in a couple of hours has led to people considering the fruits of this 'familiarisation' time as releasable games and not part of a learning experience!

These 'two hour games' (unsurprisingly) look pretty poor when compared to games written in other more difficult to learn systems where the authors have had to put in dozens if not hundreds of hours (and learned a lot about programming Interactive Fiction in the process) just to get the basics working.

2. Does it come with a data file of pre-understood words (get, drop, take etc) and can these be edited?

Yes, Quest has a built in (small) range of understood words. My extension library (called "typelib") adds a few more - and it's quite possible to add more words / commands as needed.

3. Once a game has been completed, how easy is it for others to play this game, would they need the axe software downloaded to run the game or can it run by itself?

Quest is an interpreted game runner, your eventual player will need the Quest program, but as the 'player' part is completely free, this should not be an issue - providing the player's PC uses MS Windows.

Al (MaDbRiT)

You're exaggerating on the "hundreds of hours" part; I think a person can get up to "basic proficiency" with Inform or TADS in a few hours.

Those other systems also have tons of documentation and lots of examples.

Freak wrote:You're exaggerating on the "hundreds of hours" part; I think a person can get up to "basic proficiency" with Inform or TADS in a few hours.

Those other systems also have tons of documentation and lots of examples.

I'm slowly working on a special site that will have lots of examples and tutorials on how to do common, but simple tasks in ASL/QDK.

There isn't anything on there at the moment, but if you wish to join the community forums, i'll try my best to keep you up to date with the updates of the website.

http://www.quest.chronicalgames.com

The Inform Designer's Manual 4 has over 100 examples, which handle things beyond what I've seen any Quest game do, and likewise with the DM 5. Roger Firth's site has a good list of common tasks and mistakes. It'll take a long time to equal that.

What would be a good game to see the effects and type of graphics which can be displayed and the type of gameplay that can be experienced.
Please feel free to blow your own trumpet but only if you have a decent trumpet to blow and can knock out a decent tune

Freak wrote:The Inform Designer's Manual 4 has over 100 examples, which handle things beyond what I've seen any Quest game do, and likewise with the DM 5. Roger Firth's site has a good list of common tasks and mistakes. It'll take a long time to equal that.

Perhaps a long time, but not impossible. Should the members of this community decide to work together on the Quest Centre project, the project should indeed increase in quantity of samples and the knowledge base should come to an agreeable amount, so that newer users like Cooper (Great taste in cars by the way), can use the resource and become better at developing Quest games in quicker time. The quest documentation does have contain important things that you need to know, and pretty much all you do need to know to begin a simple, yet well written (In terms of scripting) Quest game. However, the documentation is boring to read, so hopefully with Quest Centre, we can use the documentation and turn it into a resource where the user can use examples from the documentation and create small games with it.

This not only allows the user to practice with "on-the-job training", but helps them to understand and learn everything that's involved with basic Quest game development.

Freak wrote

You're exaggerating on the "hundreds of hours" part; I think a person can get up to "basic proficiency" with Inform or TADS in a few hours.

Those other systems also have tons of documentation and lots of examples.

I wrote 'DOZENS, if not hundreds of hours'. Of course it depends on the individual's starting point in programming knowledge exactly how long it takes to attain 'basic proficiency'.

Some people (especially those who understand OOP from using another language) can indeed pick up TADS in next to no time. On the other hand I know of plenty of people who've spent many, many hours trying and failing to get to grips with TADS to even a basic level.

Given that the time taken just to read the manual, tutorials and basic library of TADS is going to be more than 'a few hours', I'd suggest you are underestimating the time it takes the average Joe Tyro to achieve 'basic proficiency' with TADS(or Inform).

That's all by the by anyway. The point I was trying to make (and failing it seems) is that you can just charge straight in and point 'n click your way to something that works in Quest, wheras getting something to compile and work in (say) TADS requires you read the manual - write some code, then read the manual again to work out why what you've hand-coded doesn't compile & work as you expected it to.

In contrast, Quest requires no coding knowledge at all to make something that 'works' after a fashion - QDK writes the code for you and there's not even an obligatory compiling stage.

And yes, there are lots of examples for TADS etc. Surely these take time to read and understand as well?

While it's obviously a generalisation, I still think it takes considerably longer to make something that'll actually work in TADS/Inform than it does in Quest - but, I repeat, the results are usually superior largely as a direct result of the extra time invested.

Al (MaDbRiT)

Definately. It's strange that after playing with Visual Basic for a while now, the ASL language and features make a lot more sense. Dabbling with other languages (Not necessarily becoming an intermadiate in programming with them) can help make it easier to understand other languages. Most of them have many similarities.

MaDbRiT wrote:In contrast, Quest requires no coding knowledge at all to make something that 'works' after a fashion - QDK writes the code for you and there's not even an obligatory compiling stage.

Except, of course, when you run into problems from the QDK side of things and have to edit the source code directly to fix them. I spent more time debugging my one Quest game in this way than I did actually writing it. Judging from forum posts over the years, things haven't improved a huge amount in the meantime.

There's also the fact that the QDK interface isn't as straightforward to use as it's claimed to be. It's a longwinded and ultimately tedious process adding a custom command to the game, and a frustrating one besides considering the small size of the community and the fact that few people outside it ever play Quest games.

MaDbRiT wrote:While it's obviously a generalisation, I still think it takes considerably longer to make something that'll actually work in TADS/Inform than it does in Quest

True. But with Tads/Inform, you have a huge amount of people willing to play your game; with Quest there are far, far fewer. While that might not seem a reason in itself, no one writes games for their own amusement. They crave feedback.

You're also pitting the GUI side of Quest against the likes of Tads and Inform. That's misleading. Doing something in the Quest GUI is certainly easier than coding in Tads and Inform. But is doing something in the Quest GUI easier than it is in the Adrift GUI? No. Is coding something in the source code for Quest easier than it is in the source code for Tads or Inform? No.

DavidW wrote

Except, of course, when you run into problems from the QDK side of things and have to edit the source code directly to fix them. I spent more time debugging my one Quest game in this way than I did actually writing it. Judging from forum posts over the years, things haven't improved a huge amount in the meantime.

I would agree Q.D.K. is not as infallible as I'm sure Alex would like it to be but the intention is obviously to remove the need for writing code. That it doesn't work 100% (especially on the more complex conditional stuff) is 'unfortunate' shall we say.

There's also the fact that the QDK interface isn't as straightforward to use as it's claimed to be. It's a longwinded and ultimately tedious process adding a custom command to the game, and a frustrating one besides considering the small size of the community and the fact that few people outside it ever play Quest games.

I'm not a fan of the QDK GUI either. I'd agree the slightly more advanced stuff gets tedious to do with far too many window changes. That Quest is less popular than other systems is maybe in a small way attributable to the shortcomings of the GUI, but rather more to the fact it makes it too darn easy to generate something that 'works' but is basically dire as a game.

with Tads/Inform, you have a huge amount of people willing to play your game; with Quest there are far, far fewer. While that might not seem a reason in itself, no one writes games for their own amusement. They crave feedback.

I agree with this completely, though it's not directly related to the question(s) asked, it's a fair comment. Of course all Windows only systems are at a disadvantage in this respect to cross platform systems like Inform (an interpreter for which can probably be found pre-installed on your sandwich toaster... )

You're also pitting the GUI side of Quest against the likes of Tads and Inform. That's misleading. Doing something in the Quest GUI is certainly easier than coding in Tads and Inform.

We agree that doing something in Quest's QDK is easier than writing code in TADS/Inform. Given that our mythical beginner will opt for the easy route, 'pitting' QDK against writing Inform or TADS code is entirely reasonable and not a misleading comparison at all. I've gone to great lengths to explain how this extra ease of use actually works against Quest, because the Inform/TADS code writers have necessarily got to learn more to begin with and thus are very likely (almost certain in fact) to produce a superior product.

The question was 'is Quest easy to use' - my answer (summarised) was yes it is, but be aware that a couple of hours of QDK is no substitute for learning to program, be it in TADS/Inform or even Quest's own ASL.

But is doing something in the Quest GUI easier than it is in the Adrift GUI? No.

Frankly, I don't find the ADRIFT GUI any easier to use than the Quest one. They are different and no doubt each suits a different group of users, but I don't like either. Adrift is unarguably the more popular choice by far though.

Is coding something in the source code for Quest easier than it is in the source code for Tads or Inform? No.

I have to disagree on this, I'd place Inform and TADS as being considerably harder to write code for than Quest. Quest ASL is visual basic like, while Inform and TADS are much more C/C++ like in syntax.

The unique thing with Quest is that it has BOTH possibilities, GUI or conventional coding and you can mix both in the same piece.

Al (MaDbRiT)

MaDbRiT wrote:DavidW wrote

Except, of course, when you run into problems from the QDK side of things and have to edit the source code directly to fix them. I spent more time debugging my one Quest game in this way than I did actually writing it. Judging from forum posts over the years, things haven't improved a huge amount in the meantime.

I would agree Q.D.K. is not as infallible as I'm sure Alex would like it to be but the intention is obviously to remove the need for writing code. That it doesn't work 100% (especially on the more complex conditional stuff) is 'unfortunate' shall we say.

[quote]
There's also the fact that the QDK interface isn't as straightforward to use as it's claimed to be. It's a longwinded and ultimately tedious process adding a custom command to the game, and a frustrating one besides considering the small size of the community and the fact that few people outside it ever play Quest games.

I'm not a fan of the QDK GUI either. I'd agree the slightly more advanced stuff gets tedious to do with far too many window changes. [/quote]

Work is underway on QDK 4.0 to address both of these things - in fact the underlying stuff is now pretty much complete. Many windows have been merged which means you get far less pop-up windows. There have also been changes to the way code is handled internally which should make QDK more reliable and less likely to break or mangle code.

Keep watching the Quest 4.0 forum for more news and information, or if you have any suggestions for what you'd like to see included.

I'm directing my answer to Coop's original question.

Just how easy is it for a complete novice to use this software?

Other than being able to write HTML and a few very simple BASIC-language commands, before I began scripting code with Quest, I was a blank slate. I read and re-read the ASL guide, each time gaining a bit of new knowledge. My rooms built slowly and tediously. I got fed up with trying to learn ASL, so I decided to come back to my game later. About a year later, I sat down, determined to finish my game. Bang! Just like that! It was easy. Now I'm using "Timers" and "Status Variables" and I can actually look at the code outside of the editor and understand it. It becomes easier and easier to grasp.

For a complete beginner, I'd say you'd have to have someone else code your game for you if you wanted it any easier. As far as other editors go, I can't comment since I've only used Quest. And if you're writing a game for a general audience and are willing to advertise it to gamers who don't care what platform a game runs on, then I don't think the popularity of the software or code matters.

I did browse other Game writing software websites before I downloaded QDK Editor, and was more impressed with Quest's business structure which added to my comfortability of purchasing it.

Thank You Alex for making my dream come true,

-Witch Wyzwurd

To the various Quest regulars here, how many games have you played that were written in non-Quest IF systems, and what game(s) would you consider to be exceptional demonstrations of what Quest can do?

(The games and source I've looked through all seem to be the sort of thing which would port over to Inform pretty directly, frequently getting cleaned up in the process.)

Once again you have to understand that ASL is by far a different scripting language to what Adrift/Inform may be. As Al stated, ASL is more similar to Visual Basic (I believe there was a discussion on the old forums about ASL being highly similar to BASIC), where as the others to C/C++. As I stated myself, programming languages have many similarities, and learning more makes it easier to pick up others, but that's not to say you will advance easily.

I noticed that Alex is going to be putting Select Case abilities into the new 4.0 update. Visual Basic programs (Or atleast medium to large programs) use (or may use) several of these throughout the program, and I assume they would work in the same manner.

Being a novice programmer with only little skill compared to others, I can't say much on the major differences between the different IF game engines (Adrift, Inform, Quest etc.), but what I would assume is that Adrift and Inform (Are they actually different programs?), would be focused more towards an advanced user of scripting/programming, where as Quest is focused more towards the very new user to game creation and scripting/programming.

ASL was my first coding/scripting language, and I never really got the hang of it until I became more experienced in basic Visual Basic programming, only then did I notice the similarities between ASL and VB

I remember asking "Where do I put that in the code?". haha The first thing you need to know about programming (Or atleast with VB and ASL, I think), is that code sections are performed in order that they appear in the code itself. For example....

A couple of lines in a Visual Basic program (This one extracted from one of my own programs)...

Counter2 = Counter2 + 1
    frm.Caption = "Ranged Calc" & Counter2

This tells the Counter2 variable to increase it's current value by 1, THEN display the current value in the windows title bar.

If the code read....

frm.Caption = "Ranged Calc" & Counter2
     Counter2 = Counter2 + 1

Then the caption wouldn't display the new value, as the value was set AFTER the caption was told to change.

Same with ASL...

inc <numeric; 1>
     msg <Variable Numeric = %numeric%>

This would show the new value of the variable 'Numeric' the moment it was increased.

msg <Variable Numeric = %numeric%>
     inc <numeric; 1>

This would show the old value, and would only show the new value the next time this section of code is called, so it would be displaying false values.

Enough babbling though!!!

Everybody has their own way of wanting to do things. I agree the QDK interface does need changing a lot and it looks like it will be.

For novice users Quest/QDK is a perfect peice of software, if they wish not to have to use scripting languages etc. It's very basic but can do a lot of cool things.

I think at the end of the day, a game made with ASL can be far better than a game made with Adrift or Inform, and visa versa. Code can be poorly produced, or well produced, with both ASL and Adrift scripting.

Adrift is also aimed at non-programmers, Inform for more advanced.

I am going to download Adrift and give it a try.

You know, I'm sure the title of this thread is called 'Complete Beginner'
It started off OK and then just went down into a computer jargon rubbish
If you nerds want to have a pissing comp, go and do it somewhere else but whilst on here keep to the subject at hand.

Now, who can show me a game which would show me the capabilities of what can be done with the software

Zelimos wrote:Once again you have to understand that ASL is by far a different scripting language to what Adrift/Inform may be. As Al stated, ASL is more similar to Visual Basic (I believe there was a discussion on the old forums about ASL being highly similar to BASIC), where as the others to C/C++. As I stated myself, programming languages have many similarities, and learning more makes it easier to pick up others, but that's not to say you will advance easily.

Considering the wide variety of programming languages that exist, I'd actually put VB, C++, Inform, and Quest as being in the Algol family (block structured, imperative languages); Quest is definitely the autolier, not being designed as a context-free grammar. Compare any of them to Lisp or Prolog and see how different they are. ADRIFT is far different from any other.

For novice users Quest/QDK is a perfect peice of software, if they wish not to have to use scripting languages etc. It's very basic but can do a lot of cool things.

I think at the end of the day, a game made with ASL can be far better than a game made with Adrift or Inform, and visa versa. Code can be poorly produced, or well produced, with both ASL and Adrift scripting.

As a Missourian, I say "Show me." Programming techniques that an Inform coder will use without thinking don't seem to be possible under Quest.

BTW, why is the Quest parser / standard library effectively written in VB? Why isn't it written in ASL or CAS?



If you want an example of what can be done in Inform:
Anchorhead http://wurb.com/if/game/17
Spider and Web http://wurb.com/if/game/207

If you want an example of what can be done in ADRIFT:
The PK Girl http://wurb.com/if/game/1897

Cooper wrote:You know, I'm sure the title of this thread is called 'Complete Beginner'
It started off OK and then just went down into a computer jargon rubbish
If you nerds want to have a pissing comp, go and do it somewhere else but whilst on here keep to the subject at hand.

Now, who can show me a game which would show me the capabilities of what can be done with the software

Hey Coop,

I'm doing my best to keep to the basics, since I'm not too far away from that level myself. As far as games built with Quest showing it off: There's a download section of this webpage where you can get some games for free. But don't look to them for what you could do. If you've ever played games like the Zorks; any of these types of text games are easily doable. Furthermore, you can add sound files, there's a speech enabler to speak text, and you can add graphics and animations. Other than a few minor bugs with the Editor, which are being eliminated for the next version, I see nothing wrong with the Quest Platform.

If you're seeking to create predominately visual games, like XBox games, Quest will be a huge disappointment, since these hi-action graphic games are not its purpose.

-Witch Wyzwurd

Cooper wrote:You know, I'm sure the title of this thread is called 'Complete Beginner'
It started off OK and then just went down into a computer jargon rubbish
If you nerds want to have a pissing comp, go and do it somewhere else but whilst on here keep to the subject at hand.

Now, who can show me a game which would show me the capabilities of what can be done with the software

I'd say you were being a fair bit risky, insulting the few oldest, and most knowledgable of the forum.
Nice going!

BTW, why is the Quest parser / standard library effectively written in VB? Why isn't it written in ASL or CAS?

ASL is the interpreted language - CAS is just a file which contains ASL and other files basically zipped together.
ASL is nowhere near powerful enough to code itself in - for one there's no GUI API-commands, also not enough text parsing commands, etc.

And we've had this sort of discussion before - Alex doesn't like to think of ASL being similar to BASIC (or VB) from what I remember, although the build-in functions and the case-insensitivity (and the do <> ), do make it feel very basic-like, although the syntax is different. Also, the fact it is very command-ish, and not object-oriented is very basic too.

Counter2 = Counter2 + 1
frm.Caption = "Ranged Calc" & Counter2

Should that not be "counter2.value"?
Or is it different in VB.NET?

Tr0n wrote:

Counter2 = Counter2 + 1
frm.Caption = "Ranged Calc" & Counter2

Should that not be "counter2.value"?
Or is it different in VB.NET?

No, it's a Variable, not an object. The variable is set as Static Counter2 As Integer. Since it's a number, you can just tell it to add 1 to itself, increasing the value by whatever you set it to. Static tells VB to remember the value of Counter2 everytime the procedure is called, which makes it possible to count Counter2.

It's basically similar to incrementing a numeric variable in ASL.

Oh yeah - good ol' static....
I don't think I ever used it, as I defined (and set) variables correctly at the start of functions.
.. I may have done, although that was years ago.

I thought the counter was a timer.. Don't know why.

You *do* know about naming conventions right?

intNAME   being integer variables:
strNAME   being string variables:
blnNAME   being boolean:
lngNAME   being long:
dblNAME   being double:

It just helps make sure that you know which variable is which type - and also helps define objects:

frmNAME   VB forms:
cmdNAME   VB command button:
lstNAME   VB list box:
objNAME   Custom object:

The examples can go on - but it does help with identifying stuff, especially when browsing around code.
Also helps debugging etc.

Yes I always use name conventions, but never in variables... dunno why i've never done that, should probably start, would make life easier I guess.