Overcat wrote:Basic technical competence is a useful gauge: when large numbers of games made with a system have the same problems, it's a sign that either 1) the system is not capable of creating technically adequate games or 2) it requires a good deal of effort just to get the normal stuff working. Neither is too attractive for a user when there are alternatives where 3) basic technical competence is automatic.
An excellent argument for more built-in commands, which has been a point of small contention. Couple that with a sound manual and the games will improve.
On the other hand, the easier a system is to use, the larger a group of people will use it. The intellectual scope of the users broadens to include, well, less technically-minded individuals. And that's saying it nice. Nothing wrong with that. But this is where the Court of Games could step in as a regulatory screen.
for each object x
if x is present and text maches x.vocabulary
say "You can't cook the ", x, ".";
say "I can't understand what you want to cook."
Is there a way in Quest to determine whether the command can be understood, which does not require manually handling each object?
command <cook #object#> {
}if here <#object#> then {
if action <#object#;cook> then doaction <#object#;cook> else msg <You can't cook the #object#!>
}
else msg "I can't understand what you want to cook." command <cook #@object#> {
if here <#object#> then {
if action <#object#; cook> then {
if not property <#object#; cooked> then {
doaction <#object#; cook>
property <#object#; cooked>
}
else {
msg <That is already cooked.>
}
}
else {
msg <You can't cook that.>
}
}
else {
msg <That object is not here to cook.>
}
}For each object in locale {
If instr(#(quest.thing):alts#; #text#) > 0) then {
found object
add to found_objects array
disambiguate if array size > 1
}
return object
}If we omit the @, however, we render the alt property of the object defunct.
#@object# has always worked for me...
I may try and check this out in a spare few mins tomorrow.
command <wield #object#> {
if here <#@object#> then {
msg < Object is here.>
}
}Does the alt tag use ;'s as seperators?
command <alt #@object#> {
msg < Alt = #(object):alt#>
string <objectalt; #(object):alt#>
msg < Alt = #objectalt#>
}Alt = !
Alt = I didn't include a check for "cookability", as the fact it has a "cook" action is enough IMO
I also didn't like to check for any 'cooked', as that should be on a per-object basis under the 'cook' action.
Although I'd do it slightly seperately, and have a 2-teir system. Having a default "cookable" property, "cooked" property (as you've shown above) and a default cook action - inside an else statement. The then would be launched it the object had a cook action - in which the default wouldn't get executed.. Which allows me to go idly by adding objects with a plain property - or fill out an explosion technique of a fork in a microwave (or something).
A Simple start room. Plain white walls, and no doors.
You have a feeling you will never see anything other than these 6 white sides to this cubist's heaven!
> look one
one
two
!
!
> look two
two
one
!
> look five
five
six
!
!
> look six
six
five
!
> look seven
seven
five
!
> look nine
nine
!
!
.... Oh-oh-oh, and I don't really like types, but understand that they can be useful in a runtime situation
Tr0n wrote:quest deals with command structure totally differently from other sytems if I'm reading things like this right.
TADS/inform use a verb-pronoun-noun-whatever language structure system, which is built-in.
Ques see's it as "oh that's a line -does it match any command line which the programmer has entered?
If it does, than it goes off and executes the code.
If not, then it doesn't match any line and it gives out a "I do not recognise that command" line - which you can change.
I didn't think Quest supported inheritance?
Inheritance — a mechanism for creating subclasses, inheritance provides a way to define a (sub)class as a specialization or subtype or extension of a more general class: Dog is a subclass of Canidae, and Collie is a subclass of the (sub)class Dog. A subclass inherits all the members of its superclass(es), but it can extend their behaviour and add new members. Inheritance is the "is-a" relationship: a Dog is a Canidae. This is in contrast to composition, the "has-a" relationship: a Dog has a mother (another Dog) and has a father, etc. -Wiki
Class — the unit of definition of data and behavior (functionality) for some kind-of-thing. For example, the 'class of Dogs' might be a set which includes the various breeds of dogs. A class is the basis of modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, and the code for a class should be (relatively) self-contained and independent (as should the code for any good non-OOP function). With such modularity, the structure of a program will correspond to the aspects of the problem that the program is intended to solve. This simplifies the mapping to and from the problem and program.
Object — an instance of a class, an object (for example, "Lassie" the Dog) is the run-time manifestation (instantiation) of a particular exemplar of a class. (For the class of dogs which contains breed types, an acceptable exemplar would only be the subclass 'collie'; "Lassie" would then be an object in that subclass.) Each object has its own data, though the code within a class (or a subclass or an object) may be shared for economy.
Method (also known as message) — how code can use an object of some class. A method is a form of subroutine operating on a single object. Methods may be divided into queries returning the current state and commands changing it: a Dog could have a query Age to say how old it is, and command chase (Rabbit target) to start it chasing a rabbit. A method may also do both, but some authorities (e.g. Bertrand Meyer) recommend they be kept separate. Sometimes access to the data of an object is restricted to the methods of its class.
Multiple inheritance – a Dog is both a Pet and a Canidae – is not always supported, as it can be hard both to implement and to use well.
Encapsulation — ensuring that code outside a class sees only functional details of that class, but not implementation details. The latter are liable to change, and could allow a user to put an object in an inappropriate state. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected and private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the protected keyword to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel allows one to specify which classes may access any member.
Abstraction — the ability of a program to ignore the details of an object's (sub)class and work at a more generic level when appropriate; For example, "Lassie" the Dog may be treated as a Dog much of the time, but when appropriate she is abstracted to the level of Canidae (superclass of Dog) or Carnivora (superclass of Canidae), and so on.
Polymorphism — polymorphism is behavior that varies depending on the class in which the behavior is invoked, that is, two or more classes can react differently to the same message. For example, if Dog is commanded to speak this may elicit a Bark; if Pig is commanded to speak this may elicit an Oink.
An object-based language is a language that has most of the properties of an object-oriented language, but may lack some. For example Visual Basic lacks inheritance, while a Prototype-based programming language relies on prototypes instead of classes to create objects.
.
I thought type-inheritance was where you could have one type 'inheriting' the actions/properties (methods/properties/the-other-third-thing which might only be in VB but is like methods) of another type - but then further defines that type... Just like it says in your quote.
Quest doesn't allow types to be made from previous types.
Types: Specify here any types you want to inherit. We've discussed inheriting types in objects, but you can also inherit types into other types. For example, we might make a "poison" type, which would inherit everything from "edible" but provide its own "eat" action which would kill the player or decrease the player's health.
Follow us on Facebook
Follow @TextAdv on Twitter