Hello, All

Just wondering if anyone is working on any more libraries, or is planning to.

I have the TypeLib library (a note of Thanks to the author), and am anxious to see what other extensions of Quest are in the works.

TTFN,

Alf

ITID has released a very early battle engine, while I'm also working on one (with little monster/magic/item libraries to go with it)...

Thing is I haven't really had time to concentrate on it... I'll finish off some other stuff and hopefully get onto it during this free week I've got coming up at the end of the month.

... Anyay, what idea's did you have?

I really like the clothes/wearable, container/containable functionality added by TypeLib. I was thinking how neat it would be to have other specialty properties like edible, drinkable, etc.

How about objects which depend upon the existence (or presence) of other objects?

How about "turn based" scenarios? That is, where you can code for actions in each room to happen when the user presses the "Done with turn" button.

Or events that happen "behind the scenes". For example, you started an activity in a room. When you returned to the room at a later time, that activity has progressed to a certain degree.

I know these can be scripted, but the libraries can really cut down on the extra coding.

Once again, I'm full of ideas, just not necessarily good ones. Any other ideas and opinions - even if you disagree - are appreciated!

Alf

I really like the clothes/wearable, container/containable functionality added by TypeLib. I was thinking how neat it would be to have other specialty properties like edible, drinkable, etc.

Glad you approve The new (still unreleased though) 'typelib2' extends the existing one by allowing NPC's to have layered clothing etc, but much more useful (IMHO) is the ability to ask/tell NPC's to do things - and ask questions about objects, other NPC's and rooms etc. with what I call a 'topic based' system. Combining the two functionalities it is actually possible to ask one NPC to tell another about a third NPC (or object) - meaning your player could type:

Fred, tell Janice about the sports car.

This is particularly neat in that, prior to the above, if Fred knows about the car but Janice doesn't, after the above is made, Janice can be asked about the car and will be found to know what Fred told her - automatically

(NB. You can actually have each NPC describe the same object differently to reflect their personality if you are patient enough to do so.)

Also NPC's can be asked about themselves - obviously.

Simple types like edible/drinkable are not hard to add. Currently typelib adds 'readable' (for no other reason that I needed it for one of my pieces!)
I can add edible drinkable types to typelib2 if it's thought a good idea. Any other basic types that you would like to see in there?

How about objects which depend upon the existence (or presence) of other objects?

You've lost me here - an example of what you mean please?

How about "turn based" scenarios? That is, where you can code for actions in each room to happen when the user presses the "Done with turn" button.

You already have that functionality in Quest - in the beforeturn & afterturn scripts at global and room level.

Or events that happen "behind the scenes". For example, you started an activity in a room. When you returned to the room at a later time, that activity has progressed to a certain degree.

Obviously you can do this in script, back in Quest 2 I wrote a routine whereby you could schedule an event to proceed to completion once begun. I called this my 'daemon' script. I didn't library-ise it though, it would be a bit trickier to implement than it might seem but not impossible. I'll try and think through a solution for the next typelib.

I know these can be scripted, but the libraries can really cut down on the extra coding.

That's the idea really. I've tried to make my libraries 'plug n play' in the sense that it shouldn't be neccessary to understand the code in the libs - or even look at them - to make use of them.

Once again, I'm full of ideas, just not necessarily good ones. Any other ideas and opinions - even if you disagree - are appreciated!

Never apologise for making a genuine suggestion or constructive criticism.

Al (MaDbRiT)

Hi, Al

Thanks for the response. I'm anxious to see the next TypeLib!

The NPC interaction sounds great!

I'd like to see edible and drinkable.

Maybe consumable resources (kinda like our oil!) with start value, qty or percentage of depletion during gameplay.

That reminds me, earlier I had asked on the forum for help in filling a canteen from the lake. I got some good, workable suggestions. I tried using your scenery object, and just a regular object, but nothing quite worked without a script. That's kinda what I'm thinking of with a resource. Something that's there (and described), but it's only takeable in portions.

The existence or presence of other objects:
You can make a cake, but only if you have all the (listed) ingredients.
The engine object is made of the crankshaft, camshaft, pistons, etc. Each an object in itself, but combine to make a new object.

Does your readable property set any flags? That is: My user can't do a certain task unless he (or an NCP) has first read the manual. Would be nice if it does. Could simulate the gaining of intelligence or training.

I didn't know about the beforeturn and afterturn scripts. Guess I need to read the book again! How do we implement a "turn based" game? Just have the user type in a GO command of some sort? Do you know if any of the Quest games in the download area are turn-based? I'd be happy to look at the code to see how it's done.

From an earlier discussion, I would still like to see a way to pass parameters from one Quest game to another.

All of this is just brainstorming (while I should be working). Any thoughts?

Alf

Alf wrote;

Thanks for the response. I'm anxious to see the next TypeLib!

The NPC interaction sounds great!

I'd like to see edible and drinkable.

Those two won't be too bad to implement (though I have to make it possible for the player to tell NPC's to 'eat/drink the object' as well, just to keep the thing consistent.)

Maybe consumable resources (kinda like our oil!) with start value, qty or percentage of depletion during gameplay.

In my opinion, the status variables provided by Quest make adding a 'type' for this sort of thing not really neccessary. I might instead code a little 'example' of how to achieve the effect of depleting resources.

That reminds me, earlier I had asked on the forum for help in filling a canteen from the lake. I got some good, workable suggestions. I tried using your scenery object, and just a regular object, but nothing quite worked without a script. That's kinda what I'm thinking of with a resource. Something that's there (and described), but it's only takeable in portions.

You could do the canteen filling with objects from the typelib used creatively, but I'd say this is an area where the lake (and water) don't actually need to exist as objects at all. Using a status variable and a couple of local commands would give the effect required with minimal scripting.

The existence or presence of other objects:
You can make a cake, but only if you have all the (listed) ingredients.
The engine object is made of the crankshaft, camshaft, pistons, etc. Each an object in itself, but combine to make a new object.

This is a good 'type' suggestion, I'll add a 'TLTcomposite' to the next version of typelib. Basically this will allow the object to be 'made' only when the prescribed components are available to the player - at which point the components will disappear too.

Does your readable property set any flags? That is: My user can't do a certain task unless he (or an NCP) has first read the manual. Would be nice if it does. Could simulate the gaining of intelligence or training.

"Read" doesn't directly set a flag, but it does offer a place to write your own action that occurs as a result of reading, so you could easily use that to set a flag if that's what is needed, As a side effect of my 'topic based' conversation system it will actually be possible to do this:

a: ask an NPC about an object, receive a 'I know nothing' response,
b: tell the NPC to read a book/manual (presumably relevant to the object)
c: asak the NPC about the same object and be told what they learned from the book..

As it happens, this would involve minimal scripting - cool eh?

I didn't know about the beforeturn and afterturn scripts. Guess I need to read the book again! How do we implement a "turn based" game? Just have the user type in a GO command of some sort? Do you know if any of the Quest games in the download area are turn-based? I'd be happy to look at the code to see how it's done.

Not quite sure what you mean by 'turn based' - I'd describe Quest as 'turn based' by default!

From an earlier discussion, I would still like to see a way to pass parameters from one Quest game to another.

Ask Alex nicely

Cheers

Al (a.k.a. MaDbRiT)

Alf wrote,

Just wondering if anyone is working on any more libraries, or is planning to.

Although this might be of more interest to ORGUN than to you, I'm working on a library of functionality for *adult* themed games.

This is an extension of MaDbRiT's typelib.qlb in that it won't work in a stand-alone way. (I'd be pretty foolish to ignore all that clever clothing functionality wouldn't I?)
I'm also one of the typelib guinea pigs, so I have a good idea where it's going. Also Al, (MaDbRiT) has been extremely helpful in providing coding know how, explaining some complicated stuff in a way I could understand (no mean achievment as I'm certainly a total beginner at programming) and generally making sure my code and his dovetail together nicely.

So, there's at least one more 'library' in the works although it is a rather specialist one.

Snakecharmer

Pretty please, Alex. I *promise* to be good. Or, at least register QDK.

The code sample for resource depletion would be much appreciated. My opinion, that's one of the little things that add significant realism.

Now I'm *really* anxious to see your NCP work!

By "turn based": You may visit one or more locations in the scenario, maybe even enter commands for certain things to be done. Nothing would happen in any location until you signaled the scenario to run. That signal would step the scenario (for all the rooms/actions) only if/when the run button (or command) was signaled. I've played a game quite a while ago which was "turn" based. I'm not sure, but I think it may have been "Outpost". Anyway, it was pretty neat. On the other hand, this type of gameplay just may not be suitable to IF. Or, it may be too specialized to waste time developing.

Regardless of the takeover by graphics-based computer games, I'm one of those who still thinks that text-based games can have a place - and a market. It just hasn't been exploited, yet.

Alf

snakecharmer,

I'd be interested in your *Adult* library, although I am not making an adult game, I'm planning to build a multiplayer game and would like to have a few little things like that built in. Note that the game contains a lot of graphic (sic) violence, so will be aimed at adults anyway.

Simon

I've begun to gather ideas for a library to add new default commands / verbs to Quest.

I started a thread here :

http://www.axeuk.com/phpBB2/viewtopic.php?t=101

My final goal is to translate it into frendh for my game, but at the moment the 1st ideas / improvement can be made to the english version.
It's still very basic, I don't feel the energy to code a real and complicated library, but it could be useful in order to avoid the unrealistic "I don't understand your command. Type HELP for a list of valid commands" we can get even for some really common action verbs : listen, read, hit...

Thats a very good idea. It annoys me a little bit when games have an obvious thing to do, but you've got to figure out the correct word to use before you can do it!

Simon

Favardin wrote:

I don't feel the energy to code a real and complicated library, but it could be useful in order to avoid the unrealistic "I don't understand your command. Type HELP for a list of valid commands" we can get even for some really common action verbs : listen, read, hit...

I remember this thread cropping up before. I started to convert the ALAN set of 'verb stubs' to Quest, but then got sidetracked into improving typelib...

While there is no technical reason not to have alternative default messages (that's what these are really) for some of the more obvious commands a player might try, on the other hand giving a custom response to 'hit the widget' when at no point in the game can you actually 'hit' anything might be viewed as confusing to the player. Personally I think you need to exercise some degree of selectivity in this rather than try to cover hundreds of vague possibilities.

Recedo wrote:

It annoys me a little bit when games have an obvious thing to do, but you've got to figure out the correct word to use before you can do it!

Actually this is the OPPOSITE case to the one Favardin is suggesting. Favardin is suggesting we code responses for verbs that actually do nothing, while the case here is not coding a verb that WILL do something!

In I.F. circles, this is often called a 'guess the verb' puzzle. It is uniformly (and quite rightly) considered one of the cardinal sins of Adventure writing. The puzzle should be for the player to work out what he needs to do and having done so, every conceivable way of expressing the required solution should work.

I hesitate to say 'this is something I could easily tack on to the next typelib', because although it's true, I fear that if I don't at some point 'feature freeze' it, I'm never going to be able to release the blessed thing!

Al (MaDbRiT)

on the other hand giving a custom response to 'hit the widget' when at no point in the game can you actually 'hit' anything might be viewed as confusing to the player.

I don't wish to confuse the player, just give more "immersion" in the game, at least don't let the player feel he can't do anything at all.
For ex. if the player see a rabbit and want to attack it, it's better to give such an answer :

>attack rabbit
violence serves no useful purpose

>kiss rabbit
but the rabbit wouln't like that

so the player will understand there is nothing to do with such commands for this character, rather than "I don't understand your command". If later the player meet a bad knight, he could try to use the "attack knight" command to defeat it. And also because generally Quest designers seem to prefer to code the command associated to the action they want to perform only in the room it should be performed (for ex. command <attack knight>), if the player typed "attack rabbit" before and got "I don't understand your command", then it's not really logical to type "attack knight" later. I've seen such a case in several Quest games.
Generally Inform or Tads system already have got default answers for many commands, so people will immediately understand a command is allowed, but it's not relevant in a particular situation (the rabbit example).

It annoys me a little bit when games have an obvious thing to do, but you've got to figure out the correct word to use before you can do it!

Actually this is the OPPOSITE case to the one Favardin is suggesting. Favardin is suggesting we code responses for verbs that actually do nothing, while the case here is not coding a verb that WILL do something!

Yes and no.
those verbs could be used later in the game (ex. "cast", "carve", "read", "wear" etc...) It's up to the designers to re-use them in the future for a particular action.

and about "you've got to figure out the correct word to use before you can do it", that's why I think it's important to allow synonyms, so players could type "strike" / "attack" / "hit" / "chop" etc... if they want to attack ennemies, and not just one of those commands if the designer thought to only one of them. "Attack" command is obvious, but for some other cases, it can be difficult to find the correct syntax ("talk to", "say" or "discuss with" ?)

You're quite right Favardin, there are too many Quest games in which a command is coded only to work in a specific room, this is sloppy coding because if you tell your player that the command is 'not understood' you can't really expect him to realise that you meant 'not understood here.

Whenever a command is added locally to a room, I would consider it absolutely essential to code a global 'catch all equivalent' command that shows that the command structure is recognized but inappropriate with other objects or in other locations. For example if your player is to be allowed to 'nurdle the grudfuttock', then you can indeed allow that by adding a command to the room the grudfuttock is located in, but you must also be sure to also add a command in the game block that responds to any attempt to nurdle anything in any other location (or anything but the grudfuttock in the prescribed location) with a response like 'You can't nurdle the object' or something similar.

Personally, I dislike use of local commands. I think a properly written global command (and as I suggest above, you should ALWAYS have one even if you do have a local command) can and should be made to deal with both permitted and not permitted variations.

This approach neatly sidesteps the 'I don't understand - except when you're in this room' badness.

Al (MaDbRiT)

Hi, Al

Sounds like you've jumped a hurdle many programmers can't (or at least haven't yet). That is, you see the program from the user's prospective. That's one of the first steps to writing *good* software! Case it point: you can almost always tell when it was a developer who wrote the manual/help system. Most of the time, only another developer can understand it. This is one of the weakest links in software development. Anyway, back to topic...

I don't know if a library is the place to put it, but some kind of "global thesaurus" might be a good idea. Especially if the developer had an easy way to edit the word list to make it more compatible with the game. Morover, make the list global by default.

I like the comment about helping the player to get more immersed in the game. When you can do this, you have given the user what they want.

This is interestin', huh?

Alf

Alf wrote:

That's one of the first steps to writing *good* software! Case it point: you can almost always tell when it was a developer who wrote the manual/help system. Most of the time, only another developer can understand it. This is one of the weakest links in software development.

100% agree on this. Also, *good* software isn't always the most technically elegant, nor is it always the most efficient from a programmer's point of view. Good software is the stuff your users feel comfortable with, can pick up easily, doesn't break too often and makes sense to their way of thinking. You simply HAVE to make your product suit your intended audience, it is a cardinal sin not to.

As for manuals - a very relevant comparison is the HUGO manual written by the developer, Kent Tessman. Now HUGO is a very good IF system, Kent is an accomplished and talented coder. HUGO's manual is horrible - assumes WAY too much prior knowledge of coding in general and to be honest of HUGO in particular. I think if HUGO had the manuals and tutorials that INFORM has, HUGO would be in there challenging INFORM & TADS for popularity.

Of your other topic - a Quest library could easily add a lot of 'stub verbs' and general synonyms and is probably quite a good way to do it as it makes usage a doddle for the end user.

Al (MaDbRiT)