I am new to Quest and trying to use the QDK from a non-programmers POV.

First of all an object's property seems limited to only text strings. (Booleans seem possible, but seem a poorly indicated option in the interface.) Numbers can be entered as property values but they cant seem be be treated as numbers. It would seem to be a common thing to decrement a weapon clip ammo count or health level, or sum up the weights in the inventory to determine if the player can take another object of a certain weight, such as a small key verses a sledge hammer, both of which might open a door, one destructively, one not.

So it would be good to have object property data types.
Text (string)
Number (at least integer, if not also the option for real)
True/False (boolean)

and it would be nice to have an enumerated data type where a choice could be picked from a list of values. So a property of CoffeeTemp could be one of (Cold, Cool, Warm, Hot, and ScaldingHot).

If not adding an enumerated data type, at least the ability to define constant values that can be compared against and values copied to properties. Constants should not be changeable by the code and safe from corruption by the accidental placing of them on the wrong side of a data modifying action.

To stress what I said before, object properties are limited in Quest. Yes you can put some text into them, but testing the the property values against a fixed constant or changing the state(value) of the property has to be done with a work-around, and those are things you are likely to want to do in a dynamic game. Quest seems limited to making "static" games where things (room and object properties) dont change much. For me an improvement would be for Quest to have more clear property control where I can at least know when a property is boolean, or numeric and perform math, at least Inc and Dec on it.

I doubt that's doable without heavily changing Quest; Quest has a very limited understanding of variable typing and is largely just string interpolation.

Hi

I'm slightly puzzled by this thread, although I've pretty much 'dropped out' of Quest since version 4 came along, I am sure Quest had numeric, string and boolean variables - and that properties could also be numeric, string or boolean last time I looked.

I do believe that

property dead : - a boolean (i.e. it's true or false)
property age=15 : - a numeric (Quest deals in Integers only AFAIK)
property name=Fred : - a string.

Also increment and decrement of numeric variables is available through the inc & dec statements - with a default of 1/-1 respectively but an optional parameter that lets the inc/dec amount be specified.

I don't think you can (last time I looked) directly inc/dec numeric properties. This is a minor inconvenience, but you could probably write inc & dec functions if that REALLY bothers you. One can certainly perform simple maths and comparisons on numeric properties, my (long obsolete) 'TypeLib' library made a lot of use of that ability.

Regards to all!

Al (MaDbRiT)

Good to hear from you again MaDbRiT!

Yes, I also thought a simple:
(#object:property# + 3)

Would work.
Either that, or Using the good ol' $objectproperty(object;property)$ function to get the number:
($objectproperty(object:property)$ + 3)

And if that diamond ring still don't shine:
set numeric [ temp = #object:property# ]
set numeric [ result = %temp% + 3 ]

As for enumerated values - are you talking about during design of the game?
During the game you can have it logically, using the numbers 0 - n .. You can also have an array holding the string values. Changing the object property to property+x will give it a different value.

The only reason for you to be thinking about this is if you're creating a system for other coders to use, so that another person can create their own enumerated values - in which case, it can be botched together.

Freak wrote:I doubt that's doable without heavily changing Quest; Quest has a very limited understanding of variable typing and is largely just string interpolation.

Okay, and I understand the problems with drastic changes with a system. How about this? Make properties a sort of variant type (like I think in VB) where its stored as text, but if you do something math related to it, then Quest tries to treat the property as a number. THat way you can increment and decriment a property (if the property string can be interpreted as a number.)

I have to admit that I did not try every possible way to decrement/increment a property. I have placed my evaluation of Quest on hold for the time and turned my attention to Inform. I also need to download and try-out Adrift.

Anyway, let me try to come up, in a hurry, with an example of something I might want to do as a game maker. Now, because this is for a class, I need something non-violent.

Lets say I have a game where a box of rare comic books has somehow been scattered around the game space. I might want a "Condition" property for each comic book. The Condition property would be from a ordered list (Mint, Fine, Good, Fair, Poor, Junk) where Mint=5, Fine=4, etc. (Not sure these are the official comic book condition names, but I would research that more if I made the game.) I like code to read (If ComicBook.Condition = MintCondition Then ...) rather than (If ComicBook.Condition = 5 Then ...) (Using pseudo-code and no particular language here for example sake.) or (If ComicBook.Condition < Poor Then ..."its now Junk")

Lets say that my game logic is that I can make an array of comic books. Then each turn I can generate a random number such that there is 1/10 of a chance that one of the comics will drop one level in value (someone stepped on it, it got damp, a kid picked it up and read it, etc.) If a comic book gets damaged, then I use another random number to pick which comic book out of the array is the one to get damaged (Condition property gets decremented.). With each drop in Condition it looses half its Value (another property) from the previous condition. Another property, would of course be Title such as "Spiderman # 54". (Guessing again. I might pull real titles and current values from maybe the Overstreet Guide.)

So the goal of the game would be to search and rescue all the rare comic books before they loose too much of their value. Anyway, sorry if this is not well worked out as its off the top of my head just now.

HenryTj wrote

I like code to read (If ComicBook.Condition = MintCondition Then

I can think of a few ways to enable comparing properties in this way in Quest, none of them elegant and to be honest all of them would need pretty messy code for increment/decrement elsewhere to enable them to be used.

BUT If you wrote the 'messy code' as a library, you could effectively hide it from your coders and make it possible for them to do that kind of comparison without understanding or seeing the messy stuff behind the scenes...

This is the feature that endears Quest to me, you can tailor things a lot and just give users 'add in libraries' to make thinks simpler for them.


Having set that, I'm assuming you'd be holding the comic books in a numeric based array, so having to deal with a numeric based condition would not seem too much of a stretch to me.

Al

MaDbRiT

Comparisons eh..

I see two main ways around this:

loads of variables like:
%mint% = 5
%fine% = 4
...

When you do the comparison you can do this:

if ( #object:condition# = %mint% ) then ...

or

select case <#object:condition#>
case <%mint%>
case <%fine%>

(I hope)..

OR you can use numbers directly and comment on which is which:

if (#object:condition# > 2 ) then {
' object is worse than fine

and

select case <#object:condition#>
case <1>
' mint
case <2>
' fine

You're missing the benefits of an enumerated type / symbolic constants:

1) You can't accidentally change the value of a symbolic constant at runtime. (set numeric <mint; 17> will be prevented.)

2) If you mistype the name of a symbolic constant / enumerated type, the error is caught at compile time (or at worst load time).

Yeah.. Constants are useful for typo's I guess.

Then again, how many typo's do you actually make which assigns a value?
I also thought constants should be on the right of the comparison to also help avoid that type of problem.

With enumeration - you can have a status variable, with limits (1 - 15 for example).. With 'name.current' and "name.old' variables which are changed when the original is changed (I think the script is run after the value is changed - and that is why you need 3, and not 2, status var's).. So that changing it to an invalid number will get it changed back to the old value - effectively refusing to change.. I guess you can create a 'sort-of' constant that way, making a status variable which changes itself to the correct value if it is changed - and outputting an error message.