New to Quest (2 days) and IF in general (started researching it about a week ago, so I'm trying out several different systems.)

So far I like Quest the best (and not just because that rhymes.). But, I am having some problems already. I am trying to give an object a property that I can increment or decrement. But, best as I can tell properties can only be character strings, and maybe booleans. I think I saw another post that was similar where the advice was to convert the numeric text string into a numeric variable, perform the math there, and convert it back again. Sorry to say, but, that seems clunky. It seems that numeric object properties would be a common thing to have to work with. Is that really the solution?

Thanks in advance,
Henry

KK. I'm asuming you're using QDK, so here goes: set a numeric to the property which can be done via the string version (#object:property#). then do whatever you want with that numeric and finally set the property to its value. As asl it'd look like this:

set numeric <health; #player:health#>
inc <health; 5> ' adds 5 to 'health'.
property <player; health=%health%>

It would be nice to not have to use a temp. numeric but this method only means 3 steps/lines. Hope this helps, I'm not that great at QDK but I think can onw see what the asl looks like from QDK so you can check to see if you've done it right.

He considered that method (where the advice was to convert the numeric text string into a numeric variable, perform the math there, and convert it back again) and considered it clunky.

Thank you for the information. Yes, I am using the QDK interface. I have done little programming since my Fortran/Pascal years. (Personally I dont like the newer C-derived case sensitive languages. I think they are unnecessarily arcane.) Anyway, trying to evaluate different IF systems for a course I might teach at a community college. I need something that doesn't require programming background. (Trying out Inform and Quest-QDK at this time.)

And yes, I find this solution to be clunky. Why can game variables have a string or numeric data type, but object properties have a string (or boolean?) type? Part of the utility of variables are to modify (arithmetic, etc) and transfer data around. It seams that numeric data for objects (health level, weight, weapon clip ammo count, magic/energy level, etc.) should a common thing to do.

If you're going to be teaching, you should probably avoid Quest. It's not designed like other languages (it's not designed around a context-free grammar); it has numerous inconsistencies; there's not a lot of sample code.

Quest doesn't have a separate boolean property type; to give an object a property FOO, it puts an entry in the appropriate hashtable with key "FOO" and value ""; to give an object a property not FOO, it removes the entry with key "FOO".

Freak wrote:If you're going to be teaching, you should probably avoid Quest. It's not designed like other languages (it's not designed around a context-free grammar); it has numerous inconsistencies; there's not a lot of sample code.

From the Quest home page:

*** (copied and pasted) ***
Easily create your own text adventure games

Quest brings 1980's-style text adventure games up to date. Now you can create your own exciting text adventure, and you don't need to know how to program.

Easy-to-use visual editor
No programming required. Everything about your game is displayed in plain English, and a full tutorial is included. If you've ever wanted to create your own game, but have been put off by complicated programming languages, Quest is a great way to get started.
***

So it sourds like you are saying that the above is incorrect. Then maybe someone should tell the makers of this system. Then they can either change the wording on the web page or improve the program.

lolz. There is samples and such, in the tutorials. i find asl, the quest programming language. If you want help in planning lessons in quest and finding stuff out, I'll be happy to help.

I always think a good way of seeing the strengths of a program and what it's capable of is to download some of the games written with it and play them.

That doesn't necessarily work, though. We have yet to see a game that properly uses the full potential of Quest, and frankly, I'm unsure if we will. I seriously hope we do, as there is definitely a future in the system, but we don't seem to be attracting any IF fanatics, or real coders. It seems to only be the dabblers that make it to Quest.

My game was pushing quest's limits quite nicely, doing things I didn't think posiible until I tried to do them with my tricky little coding (though there are parts of code I did years ago and have no clue how they work but they do, it's scarey). If anybody wants my codes they can ask. Also I think Lyteside's game was so huge he had to wait til Quest up'ed the maximum lines so he could contiue. It's no where near finished though he tells me. I may be working on my game this summer or turning it into an orpg engine for quest, either way i'll be finishing off the feature list i made, and hopefully it'll push some more limits.

S1aY3R wrote:That doesn't necessarily work, though. We have yet to see a game that properly uses the full potential of Quest, and frankly, I'm unsure if we will. I seriously hope we do, as there is definitely a future in the system, but we don't seem to be attracting any IF fanatics, or real coders. It seems to only be the dabblers that make it to Quest.

True, but I'd have said the very fact that no one has yet written a game that uses the full potential of Quest, despite the fact that it's been out for nearly a decade in one form or another, speaks volumes.

I doubt anybody will ever use the full potential of any system, but even the highly-rated Quest games I've played rarely rise above the technical level that Inform / TADS programmers tend to take for granted.

Freak wrote:I doubt anybody will ever use the full potential of any system, but even the highly-rated Quest games I've played rarely rise above the technical level that Inform / TADS programmers tend to take for granted.

True in that any one application rare uses all the features of a system, but one game might make heavy use of one feature while a different game makes extensive use of a different feature.

THe problem I am seeing with Quest is that is seems not to be rigorously worked out. (AS someone pointed out that it lacks a rigorous context free grammar and therefore has inconsistencies and perhaps gaps in its abilities.) There is a difference between writing an application and designing a system. Sorta like the difference between a brick-layer building a wall, and an architect designing a building.

I think Quest, and QDK, has good potential, but its not there yet.

To answer the original question, you can do it in one line. Here's a modified version of Elexxorine's code:

property <player; health={#player:health# + 5}>

This makes use of the ability in Quest 4.0 to evaluate an expression anywhere, by surrounding it in curly brackets.

If you're using QDK, in the Script Editor you need to select the "Modify" category, then "Property". From "Object or Room name", choose "player", and then enter the following in the "Property data" box:

health={#player:health# + 5}

Incidentally, I'm sure Quest's apparent lack of a "context free grammar" has been explained to me before, but I'm not sure I've fully grasped what this actually means in terms of missing features (or confusing behaviour). Specific feature requests are always welcome though!

Alex wrote:To answer the original question, you can do it in one line. Here's a modified version of Elexxorine's code:

property <player; health={#player:health# + 5}>

This makes use of the ability in Quest 4.0 to evaluate an expression anywhere, by surrounding it in curly brackets.

Ick. I think that

player.health = player.health + 5;

and the general rule of treating as expressions by default is cleaner.

Incidentally, I'm sure Quest's apparent lack of a "context free grammar" has been explained to me before, but I'm not sure I've fully grasped what this actually means in terms of missing features (or confusing behaviour). Specific feature requests are always welcome though!

The grammar refers to how the source file is defined; a context-free grammar is at a balance of being able to handle complex behavior while still being machine readable in reasonable time. CFGs are good at reducing the need for code duplication within a parser, so such languages tend to be consistent. A regular grammar can not handle nested braces on its own; Quest uses a number of ad hoc mechanisms to handle braces and comparisons in parens which don't quite work.

Thank you for the excellent answer.

I think Quest has good promise as a system. But it still lacks some generally useful features. To some extent, IF are a "state change" system. Quest makes a good start is setting up such a IF/game system, but it still lacks the ability to adiquately define certain kinds of "states" and additionally the rules that work on them. IT would be nice to define a limited (and named) set of states. Such as the comic book condition that I mentioned, perhaps in another thread. (MintCondition, FineCondition, GoodCondition, PoorCondition, etc.) Then be able to set and compare the Condition state of a comic book objects to these named contition. In some cases it makes sense to allow the condition states to be "ordered." So decrimenting the Condition state would deteriorate the comic book, etc.

I certainly hope Quest continues to improve and develop.

henrytj wrote:Thank you for the excellent answer.
IT would be nice to define a limited (and named) set of states. Such as the comic book condition that I mentioned, perhaps in another thread. (MintCondition, FineCondition, GoodCondition, PoorCondition, etc.) Then be able to set and compare the Condition state of a comic book objects to these named contition. In some cases it makes sense to allow the condition states to be "ordered." So decrementing the Condition state would deteriorate the comic book, etc.

Create a type (let's say Collectible) that includes a property named condition (even treat it like a string if you like). Include the following actions (compare, increment, decrement). Lookie here, you get to define the exact logic / rules for those actions without having to depend on or being forced into a certain style. Heck, you can even capitalize any letter(s) you like.

Now, any object you add type collectible to can be treated with
myObject; compare
myObject; increment
myObject; decrement

Not to mention it is now useful for anything collectible object (NOT just comics).

Thank goodness we, as programmers are not limited (er forced) to program in one way without the flexibility to think outside the box to elegantly and simply solve routine problems.

henrytj wrote:Thank you for the excellent answer.

I think Quest has good promise as a system.

I thought that when I first encountered Quest. Then I tried to clone the Quest runner (project Geas), and had to really analyze it.