Seriously. I just downloaded the latest two "games" (it's almost insulting to proper games to call them that) on the Quest games page and two seconds after starting, I'm shuddering at how dire they are.

Why do people even bother uploading such trash? Surely not even the writers can like these games.

You should see the stuff that I reject!

You mean those are the ones that got through?

I don't think I'd survive an encounter with the rejected games.

I'm not sure what's the most popular adventure engine out there, I'm guessing TADS but then again TADS (to my knowledge) does not have something like a GUI engine like the QDK. It's all text editor scripting. However there do seem to be more tads games than quest games, though tads probably also has been around longer. The other reason you might not see many quest games (on this site anyway) is some authors have not yet submitted them. I know of a few quest games floating around certain yahoo groups that are not on this site. Then again they are also not technically completed games either.

There is a dilemma in the TADS community where html TADS has not caught on yet or been updated to have all the commands of tads 3 (or something like that anyhow). So because of that (and some bugs I just don't like about tads) I've held off writing code in that and have been trying to write up something in quest. I'll eventually submit my game here, but it has a long way to go before I get all the kinks worked out in the code, and already the source code is over half a megabyte in size.

I'm trying something like a recreation of the old Hewlett Packard mainframe game "Mystery Mansion" (from the mid '70's). It's going to take time to write up all those routines though (put rope over wall, open door, forward, backward, turn left, turn right, open drapes, turn on light, dig hole with shovel, question butler, use phone, etc.) Since no library exists with these types of commands already in place I have to write everything from scratch, and it's a bit time consuming. I'm sure other quest authors are encountering these same sorts of problems. If there was a big library available we could get these games out faster I think, but that will take time.

I quite agree. Without a big library especially devoted to these commands, we have to create them ourselves. If someone like MaDbRiT could write another library devoted to commands like the ones stated in Billchelonis described, things would be a whole lot easier and I'm sure that a lot more Quest games would come out sooner. What would be even easier is if Alex implemented some of these commands into Quest.

I've also started using ADRIFT over the past few weeks and that has built in commands for standing, sitting and lying on objects, turning objects on and off, closing and opening objects, locking objects, using an object as a shield or weapon in a battle engine, as well as commands that exist in MaDbRiT's TypeLib, like reading an object and using an object as a container. Plus it has a character implementation so that objects are separate from characters.

If Alex could implement some of these features in Quest, or MaDbRiT could write a library for some of these commands, I think a lot more Quest games will appear a lot sooner rather than later.

I've also started using ADRIFT over the past few weeks and that has built in commands for standing, sitting and lying on objects, turning objects on and off, closing and opening objects, locking objects, using an object as a shield or weapon in a battle engine, as well as commands that exist in MaDbRiT's TypeLib, like reading an object and using an object as a container. Plus it has a character implementation so that objects are separate from characters.

The ADRIFT object set is I think modelled on, (maybe even uses) a TADS adventure 'library', which is why it has those TADS like features. Strangely enough objects and characters were discrete and different in QUEST too until reasonably recently (Q3? Alex can correct me if I'm wrong). Because you can now use types in Quest now it really doesn't matter anyway. I implement a character type 'TLT_Actor' in my old typelib.qlb and this is effectively the same as having the two still seperate.

If Alex could implement some of these features in Quest, or MaDbRiT could write a library for some of these commands, I think a lot more Quest games will appear a lot sooner rather than later.

I'd hope you were right on the last point - With the addition of the words 'good quality'.

Libraries of re-usable code are actually quite tricky to do well. Not in the coding sense (although they can get hairy!) but from the point of view of making them both broad ranging enough to be flexible an useful in many cases, yet precise enough to require minimal work from the end user to implement and able to deal with lots of possible variations. This is something of a balancing act to get right.

I don't think putting more hard coded functionality into Quest is a good idea at all, it makes things much more difficult to override when you want non-standard behaviour. As a matter of interest Mike Roberts (TADS author) has deliberately moved pretty much all of the hard coded interaction out of the TADS engine in TADS 3.0 and put it into a bigger, user customisable library. This makes TADS 3.0 more flexible than any previous version - a 'Good Thing'. If Mike Roberts and the assembled wisdom of all those TADS experts think that transferring interaction out of the engine and into a library is the way to go, I'd certainly give that weight of opinion the utmost respect.

My own 'Typelib 2' (which WILL get released eventually) does add a lot more commands to Quest, but basically most are aimed at making the 'TLT_Actor' appear more lifelike. Things like "tell Fred to pick up the booby trap", "Ask Fred about the widget", "Fred, put on the diving suit" are dealt with by having implemented a quite complex "TLT_Topic" type (something that can be asked/told about), extending the clothing types to work with NPC's and altering almost everything else in the library so that a player may instruct a NPC to do something he might otherwise do himself. These make for very complicated 'types' as you might imagine.

I am planning to add 'chair', 'bed' & 'vehicle' types to Typelib (sometime) and therefore 'sit on / lie on / stand on / ride in/on commands to suit. A 'battle engine' is an altogether different thing - I think that would best be done as an entirely separate library to be included only in games that feature combat, rather than as part of a general extension library such as 'Typelib 2'.

What I've not done is implement very many easy to do types. 'TLT_Readable' is a good example of a type I *have* implemented which is (relatively speaking) pretty simple. Typelib already provides an openable/closeable' type, I think it would be trivial to add 'locked/unlocked' to that type - but should I do that as part of the library or allow that to be left to the library's end user?

It might be advantageous add to the library a bunch of simple 'stub commands'. By this I mean code up some minimal default responses to user input like 'eat the apple'. Rather than go the whole hog and code an edible type (which isn't actually very hard, but that's another story!) the command would simply test the object (apple in this case) to see if it has an 'eat' action. If the test fails the library would respond with a 'You/He/She can't eat things like that.' otherwise it would call the 'eat' action it found.

This makes 'eat (whatever)' understood as a legal command, but doesn't provide any real functionality - which is why I call it a 'stub command'.

Obviously if the end user now adds an 'eat' action to the apple object, this would be run in response to 'eat apple'. Thus an action might be written to increase the players strength or kill him if it is poisoned, destroy the apple and so on.

Adding lots of commands of this type would be very easy to do - but the result wouldn't be so easy to use - requiring the author to manually write actions (there would be no QDK interface for the stub command) rather than just tick boxes and provide messages the way a fully implemented 'edible type' allows.

So therein lies the library designer's quandry - does one add loads of these 'stub commands', or just keep the library for fully implemented types only?

It'll be interesting to canvas opinion / discuss this one further

Al (MaDbRiT)

I think one of the main failings with Quest right now is its, for want of a better word, fiddlyness.

Adding custom commands is one of the things that every game needs because the commands that are covered are, frankly, not up to much. Yet rather than a simple one-click to add a custom command, I need to click on Game -> Properties -> Global Settings -> Edit Custom Player Commands -> Add and then finally I can enter the command I want. Wouldn't it be easier to just have an icon in the main QDK interface that I could click on to add a command? It would certainly save time. The way things are now, adding custom commands is such a tedious and long drawn out process that most people don't seem to bother.

It's also very fiddly adding items and there seem to be one hell of a lot of unnecessary options here: prefix, suffix, detail, display type, not to mention the strange idea of lumping in characters and objects together. This way, every time I add a character to a game I have a make a point of making them "not takeable" or have it possible for the player to pick them up and carry them around as if they were normal objects. It might be a better idea to separate the two: have one area for objects and another for characters.

I also think Quest needs to recognise a few more basic commands. When I wrote a game I was surprised to find the program didn't understand the "wear" command, one of the most commonly used commands in text adventures since the dawn of computers! I suppose I could create a custom one but, really, shouldn't Quest cover at least the basic commands and not leave the poor writer with the forbidding task of creating every command they're going to need in a game?

The way Quest is now, it has potential but its GUI isn't a patch on Adrift's and nor is it anywhere near as straightforward and easy to use. And if you're just going to hand code everything, it lacks the power of either Tads or Inform, which has pretty much left it behind in the text adventure market. Games might be getting written for it, but as they're all pretty much drivel that's no big deal.


EDIT: another thing that really bugs me although no one else seems to have mentioned it so maybe it's just me. Too many pop up windows! Seriously, you edit a command and have to click your way through a dozen or more windows to get to the bit you want to change and then close down every one of the windows. Is there any need for so many windows? Why not just have one?

I think one of the main failings with Quest right now is its, for want of a better word, fiddlyness.

Ooh, I do like the word 'fiddlyness' (wish I had thought of it ) and I do agree Q.D.K. does tend to appear to suffer that way, but it is hard to see how it could be improved without sacrificing control.

Adding custom commands is one of the things that every game needs because the commands that are covered are, frankly, not up to much. Yet rather than a simple one-click to add a custom command, I need to click on Game -> Properties -> Global Settings -> Edit Custom Player Commands -> Add and then finally I can enter the command I want. Wouldn't it be easier to just have an icon in the main QDK interface that I could click on to add a command? It would certainly save time. The way things are now, adding custom commands is such a tedious and long drawn out process that most people don't seem to bother.

I agree the inbuilt command set is kind of minimal, but as I said in my previous post, I think that is a Good Thing. TADS & INFORM get their power from the add in libraries of commands & objects which means we can change things when we want, hard coding too much restricts flexibility. I must admit I agree that the custom commands are kind of 'buried' in the QDK interface a bit too deeply for my liking though.

It's also very fiddly adding items and there seem to be one hell of a lot of unnecessary options here: prefix, suffix, detail, display type, not to mention the strange idea of lumping in characters and objects together. This way, every time I add a character to a game I have a make a point of making them "not takeable" or have it possible for the player to pick them up and carry them around as if they were normal objects. It might be a better idea to separate the two: have one area for objects and another for characters.

Unnecessary? as they are options surely you can safely ignore those you don't want - at least the options are there when and if you need them. Of course that means they clutter up the interface when you don't want them, I'm not at all sure you can avoid that. This is one of those 'judgement calls' weighing up more options offered (i.e. flexibility) against simpler appearance (less flexibility). I don't find that characters being objects is a problem at all, but then I use my own TLT_Actor type derived from the base object which makes setting up a simple actor a tick one check box in QDK exercise.

I also think Quest needs to recognise a few more basic commands. When I wrote a game I was surprised to find the program didn't understand the "wear" command, one of the most commonly used commands in text adventures since the dawn of computers! I suppose I could create a custom one but, really, shouldn't Quest cover at least the basic commands and not leave the poor writer with the forbidding task of creating every command they're going to need in a game?

Exactly the point I was trying to 'get at' in my original posting in this thread. Yes, I agree Quest needs to have more ready made commands like wear, read, open & close available to the user 'by default'. However, at the risk of repeating myself, I don't think they should be hard coded into the Quest engine. I subscribe to the idea that these would be better (i.e. more flexibly) provided by way of a library or libraries. This is how TADS, HUGO, INFORM, ALAN etc do it - these are the 'big players' of IF and I think that is significant.

This is why I've tried since Q2.01 (and continue to try) to produce libraries to add commands for Quest - so far I'm ploughing a lone furrow on this one unfortunately. I've tended to go for a very 'full' treatment of objects and related commands with lots of user 'tailorability' in my libraries, but maybe I should provide more commands/objects but keep them simpler? Without a lot of feedback I'm tending to write them to suit my own purposes as much as anything.

The way Quest is now, it has potential but its GUI isn't a patch on Adrift's and nor is it anywhere near as straightforward and easy to use. And if you're just going to hand code everything, it lacks the power of either Tads or Inform, which has pretty much left it behind in the text adventure market. Games might be getting written for it, but as they're all pretty much drivel that's no big deal.

I don't actually agree with you regarding ADRIFT's GUI, I find it (and ADRIFT generally) curiously awkward and restrictive in use. I'm not 'knocking' ADRIFT here, it's a fine system for sure, this is merely my personal preference. Just as I prefer the feel of TADS to Inform because it 'makes more sense' to my mindset although I recognise both are excellent and (basically) pretty evenly matched.

Power wise, I think Quest is pitched somewhere between Adrift & Inform/TADS, that means it is pretty sure to be more 'difficult' than ADRIFT and less 'difficult' than TADS - 'you pays your money and takes your choice' as they say...

EDIT: another thing that really bugs me although no one else seems to have mentioned it so maybe it's just me. Too many pop up windows! Seriously, you edit a command and have to click your way through a dozen or more windows to get to the bit you want to change and then close down every one of the windows. Is there any need for so many windows? Why not just have one?

While there are lots of levels of pop up windows in Q.D.K. generally, I'm not sure that this is avoidable. If Alex dramatically increased the content at each 'level' it would make things look even more cluttered than they already are and things might not be so logically grouped. A designer with 60 related options to present to the end user has to pick a method somewhere between having 1 'window' with all 60 options on it or 60 'windows' with 1 each. Most people would consider either extreme very poor interface design, but deciding the way to 'split up' the options and over how many windows is very much a question of taste.
Personally I too would prefer rather fewer levels of windows than at present and would not find the inevitable increase in 'options per page' too distressing - but ask a dozen programmers to design an interface and you'll get 12 different ideas on what's best.


Al (MaDbRiT)

Well, the cluttered pop-up window thingy I have to also agree on... Many times have I been through 10 or more conditional pop-ups and then other pop-ups for text etc...

Maybe have one "node" window for the comands/conditional statements within a function/whatever, have the user select where he wants to insert the conditional/action and then have the pop-up come up... That way it'll only go about 3 pop-up pages deep... Instead of the millions before.

I also think maybe an open-source library would be good... Where someone monitors a main file, then people write in with additions to the command set and additions to the coices of the command set too...
Each command would be given a "default" setting, with the ability to over-ride this default by a simple override property in the object (ie, OR_#commandname# = 1) and additional settings with be given a "type" number... Much like functions...

Ie (and thisis using a pretty wild mixture of laguages here!):
Function "Math" (OR, ORW, TYPE, NUM1, NUM2)
if OR = 1 then {
execute "ORW" * Obviously you'd put in some code and standardise a way to pass custom commands here...
} elseif TYPE = 1 then {
return "NUM1 * NUM2"
} elseif TYPE = 2 then {
return "NUM1 / NUM2"
}
etc...

Now I know it's just a rough idea/outline... But I think if a change was wanted a vote could be held by the coders and so a majority vote would win. It would be backwards compatible if you added settings onto the end and maybe a version number at the beginning. There'd be one guy taking submissions and writing it up, producing one copy... I think that would be definately good for the coders - and also allw some of use advanced coders the freedom of not writing a WHOLE library, but instead contribute parts... Therefore not becoming a major project or eating our free time.

As an example of the kind of library I mean, take NWN (Neverwinter Nights) Content Expansion Pack (CEP). Though a 3D role playing game, NWN has some nice code examples in their CEP library. In fact, I basically lifted the code from there on how to handle door objects in Quest by using various properties tags on each "side" of the door. Not sure how much more of the CEP I can snag and copy for use in a text adventure though, but the CEP library is fairly impressive for something basically the users came together with and put together.

Some links regarding the NWN CEP:
Library standards:
http://nwvault.ign.com/dm/resources/Com ... Pack.shtml

Community Expansion Pack:
http://nwn.bioware.com/players/cep.html
http://www.nwncep.com/

I think they even went so far as to include an optional patcher program to check for CEP updates. That would be a good idea if we built a community quest library so that everyone was able to have the same working version of the library, and be sure to always include backwards compatability for any deprecated commands so loading the newer library doesn't mess up a game designed with an older version.

- Bill

I need to click on Game -> Properties -> Global Settings -> Edit Custom Player Commands -> Add and then finally

I think QDK is good for the skeleton of the game. If you want to properly add such new commands, then you should edit with an ascii editor. It's very quick to do so.

	command <take all> msg <You can't take all.>
	command <x self; look myself; x myself; examine myself; examine self> msg <You are yourself, it's already much, few people could claim the same.>
	command <hints> displaytext <hints>
	command <walkthrough; solution> displaytext <walkthrough>

	command <dirs> {
		if not ( #quest.doorways.out# =  ) then msg <You can go out to #quest.doorways.out#.>
		if not ( #quest.doorways.dirs# =  ) then msg <You can go #quest.doorways.dirs#.>
		if not ( #quest.doorways.places# =  ) then msg <You can go to #quest.doorways.places#.>
	}
	command <objects> {
		if not ( #quest.objects# =  ) then msg <You can see in your surroundings :|n#quest.formatobjects#.|n>
	}
	command <give #@thing# to #@destinataire#> {
		if ( #destinataire# = Livolas ) then {
			msg <Livolas thanks you for the #@thing#.>
		lose <#@thing#>
		hide <#@thing#> 
		} else <This person doesn't want this item now.>
	}
	command <put #@thing# in #@container#> {
		if property <#container#; container> then msg <You put #quest.error.gender# #thing# in #container#> else msg <You can't put #quest.error.gender# #thing# in this.>

But otherwise I totally agree with you.

I think the two main reasons why there are so many "bad" Quest games, are those :

- Many good author don't want to bother using a tool such as QDK (even if it's a good tool). And they expect also many built-in commands for the most actions. For example they don't want to have to code themselves the default reply for "wear".

- Most of the good authors (look at rec.arts.int-fiction) are using linux / unix without problem, and probably most of their time. So they can't use Quest easily, and it's probably not a problem for them to run a system (Tads, Inform) that is more difficult to code, but which has more library, and more "mature" for them

It's a pity, but it's such. I hope it will change in the future, and new authors will release good games on Quest.

But they will need to have some libraries for helping them, probably. I posted in the past about this issue. I don't consider myself as a good author, but I began to write a game with Inform. It's good, but sometimes tricky to use. I found more flexibilities and ease with Quest. I want to port my Quest game into french, and think when it will be finished it will be above several quest games in the archives. It won't be a revolution or a wonderfull games, but I want it to be pleasant to play (and maybe to find someone for correcting my english in the final release, but my aim is for the french "market"). I tried to include many additional commands, only not to disappoint the player who want to test some words. So I'm working on this kind of library : (the commands without 'msg' are the ones that need to be finished)

	command <blow in #@objects#> msg <Blowing in this doesn't make any interesting sound.>
	command <borrow #@objects# from #@actor#> msg <You can't achieve it this way.>
	command <buy #@object#> msg <#quest.error.article# is not for sale>
	command	<bring>
	command	<cancel>
	command	<cast>
	command	<carve, dig, pick>
	command	<change>
	command	<clean>
	command	<climb>
	command	<close>
	command	<comb>
	command	<complain> msg <Don't complain all the time !>
	command	<cook> msg <Maybe it's not time to cook now ?>
	command	<cough> msg <Reuf, reuf>
	command	<count>
	command <commit suicide> playerlose
	command <cry> msg <You don't need to do that now. Crying can't be made on command.>
	command <cut #@quest.objects#> {
		if property <#quest.objects#; breakable> then {
		msg <You torn #quest.error.gender# #quest.objects# to pieces, and nothing usefull remains.>
		conceal <#quest.objects#>
		}
		}
	command <change #@quest.objects#> msg <Change what ?>
	command	<crawl>
	command	<dance> msg <You dance a bit for your own pleasure>
	command	<desire>
	command	<detach>
	command	<dive>
	command	<dig>
	command	<draw>
	command	<dream>
	command	<drive>
	command <drink #@quest.objects#> {
		if property <#quest.objects#; drinkable> then {
		msg <You drink #quest.error.gender# #quest.objects#>
		conceal <#quest.objects#>
		} 
		else msg <#quest.error.gender# #quest.objects# doesn't seem good to drink, you should forget this.>
		}
	command <eat #@quest.objects#> {
		if property <#quest.objects#; edible> then {
		msg <You eat #quest.error.gender# #quest.objects#>
		conceal <#quest.objects#>
		} 
		else { 
			msg <#quest.error.gender# #quest.objects# doesn't appear appetizing, you shouldn't do this.>
			}
		}

Another big problem is the fact that a lot of people don't like to hand-code, because it's sort of like programming. Meaning that most people DON'T find it easy to add new properties and commands in a text editor

007bond wrote:Another big problem is the fact that a lot of people don't like to hand-code, because it's sort of like programming. Meaning that most people DON'T find it easy to add new properties and commands in a text editor

Exactly.

The thing that initially attracted me to Quest was the fact that it has a GUI. I don't know how to code and I don't have any great desire to learn so coding a game is out of the question for me. However, if I was going to code something I wouldn't use Quest. I'd use Tads or Inform because they have a far better reputation than Quest, a better interface and a massive resource of libraries. Sure, I'd still have to code the game itself but a lot of the tedious work would already be taken care of.

Quest's selling point is its GUI which at the moment needs a serious reworking in order to attract people.

I can understand what you mean, but believe me : even when coding "by hand", Quest is more pleasant than Inform, and I find it more natural to use (ASL I mean). Also the ASL habiliy to be run as an interpreted language, without the need to compile it, is very cleaver. It seems it's the only IF system that allows this.

I think the QDK is very good for begining a game, and also for setting the first functions, procedures, commands, flags and so on.
I don't like writing code from scratch. I never did it, even with Inform.
But the QDK is perfect :
- for showing how the code is written (then you only have to copy, paste and modify)
- for cleaning the code
I find it conveniant to use

Without QDK I wouldn't have started writing a game in Quest, but now the hand-coding is quicker to use. The game is big too (almost 100 ko) so it's better to use a text editor. And I sometime still use the QDK for having a general overview of the game, and for cleaning the code.

Talking about bad and good games, I've just seen that with the new games you mention, there are also "War of Hyrule Castle" and "Kenny's Christmas Presents" (I hadn't checked the new games for a while), they are worth looking. There are still lacking some commands, but they look enjoyable to play.

About good author using Quest, I remember now "Chuck" was here some time ago, he released a good game made with Suds (http://www.ksu.edu/wwparent/story/nature/index.htm). He planned to make a game with Quest, I hope he's still working on this .

I think libraries of objects that can be used from QDK with a few clicks and filling in a few parameters are a wonderful idea, making things that would seriously challenge my ability to code for myself plug and play simple to implement.

Expert coders probably don't need libraries at all, so I think the priority with libraries should be that they be as easy to use from QDK as possible.

Regarding backwards compatability of libraries, while it certainly matters a lot with add ons to an existing game (such as the online RPG mentioned above) and would be convenient for the coders in Quest, I really don't think it is all that important.

I say this because in distributing a Quest game, I would imagine most people would prefer to release a compiled CAS file. This being the case, (as I understand it) whichever generation of the library one had used to develop a game would be 'crunched' into one file along with the ASL file that required it, the two becoming one entirely self contained whole. That means that the presence of another version of the library on a player's computer wouldn't matter at all.

This also means a game doesn't have to be packed with instructions like "you must have version 22b of MaDbRiT's typelib.qlb or later to run this game"

I guess I'm trying to say that as I don't think the end player should need a coding library for a game to run on her/his PC, so coder's libraries can exist in many forms, even incompatible ones, without causing problems.

As I said above though, I do recognise that it would convenient for these coder's libs to be backward compatible, but if breaking that rule allows a big improvement in what the library can do, I'd prefer the improvements.

One can always continue to use the old library anyway.

Ali G

Farvardin is right, Quest is about the only IF Creator that lets you edit the code straight from a text editor. Fortunately for Alex though people prefer the GUI and end up buying Quest Pro

Expert coders probably don't need libraries at all, so I think the priority with libraries should be that they be as easy to use from QDK as possible.

I think they DO need libraries, because even if they are "expert coders", they probably don't want to spend their time coding basic things. The most popular IF systems have dozens of advanced libraries available.

For the rest, you're right, in a compiled game, old libraries won't interfere with the news.

Quest is about the only IF Creator that lets you edit the code straight from a text editor

yes, binary code for IF is not good (cf SUDS, ADRIFT (I think) etc.)
Most of the time I prefer to code by hand, but even now I load my game in QDK for arranging a few things (doors and such)

I think they DO need libraries, because even if they are "expert coders", they probably don't want to spend their time coding basic things.

I suspect that Snakecharmer was thinking of the all-encompassing 'typelib.qlb/q3EXT.qlb' type of library that provides very detailed objects for easy QDK use. I know she has mentioned to me that while these probably suit the non manual coding author perfectly, they might be too rigid (despite my best intentions to make them not so) for those who code manually.

In other words, QDK users & manual coders may well have different ideas of what a library should do, the QDK user wanting to tailor from loads of ready made options, the manual coder just wanting the bare bones to flesh out to meet his or her requirements.

A good example is eating and drinking. I could (maybe should) add edible and drinkable types to typelib for the QDK user. As anyone who can code manually will realise, it is actually pretty trivial to code 'eat' and 'drink' commands for any object that requires them so adding objects to typelib to enable them would be regarded as not required by this group.

On the other hand 'lock' and 'unlock' aren't so easy to do, they require 'key' objects, they impact on 'open' and 'close' commands, they can relate to containers and doors - it would therefore be useful to all if a 'lockable' and 'key' types were included in Typelib (or something similar.)

I've been through the ALAN library, and of the functionality it provides, came up with the following list of things Quest currently doesn't handle (I'm assuming my typelib_2 is loaded to provide containers, actors, conversation objects, clothes etc) and marked the list either 'trivial' or ' library' -

attack: shoot: hit [with] - needs a discrete "combat library"
verbose/brief: - Library
eat: drink - trivial
hint: - a seperate 'hint library maybe?
jump on: jump - trivial
kiss -trivial
knock [on] - trivial
listen [to] - trivial
lock: unlock [with] - Library
push: pull - trivial
smell: - trivial
throw [at] - trivial (mostly!)
touch [with] - trivial
turn on, switch on & off - mostly trivial
sit on: lie on: stand on - library

I think some other stuff NOT in ALAN ought to be added - like -

vehicles - library
doors (between locations)- library

Be interesting to see how other people view this. I am planning to add 'doors' (and locks etc) 'bed and chair' items (sit/lie/stand) to typelib_2. I don't plan to add vehicles (do that seperately) and a combat lib DEFINITELY needs to be done as a stand alone.

Al MaDbRiT

Hi, Al. I like your ideas about doors, etc. Pretty much any scenario required some sort of passage from one location to another. Doors, keys, locks, and all the variances of each are part of any scenario I've ever seen, and any I can think of. I know you can script these, but object properties sure makes it much easier!

How about different libs for different object groups? A lib for living/biologic objects would include coding for properties of living things (alive, hungry, sleepy, size, weight, other stuff). A lib for scenery (trees, lakes, rivers) that are interacted with but you generally can't take them with you. If I define an object now like a lake, it shows up in the list of objects. I would rather have it there, but not have to take it to get a drink. I must add that, given your current lib, you know a LOT more about lib contents than I do. Too, I guess there are different opinions as to having one large lib or several smaller one.

Your thoughts?

Alf

PS - After writing this and reviewing it, I realized that a lot of my ideas come from programming with objects. I keep forgetting that IF scripting conveys the same ideas to the player. Rather than deleting the message, I thought I'd post it anyway and get other opinions.

Alf wrote

How about different libs for different object groups? A lib for living/biologic objects would include coding for properties of living things (alive, hungry, sleepy, size, weight, other stuff). A lib for scenery (trees, lakes, rivers) that are interacted with but you generally can't take them with you. If I define an object now like a lake, it shows up in the list of objects. I would rather have it there, but not have to take it to get a drink.

Breaking a lib into component modules that deal with specific areas is a Good Idea, it it how ALAN works and makes altering individual 'areas' that much easier. The fact that Quest is pretty object oriented itself these days means that the logical division is indeed into groups of related objects. However when writing typelib I realised that some things really can't be 'modularised' very well because there is so much crossover with objects (or more accurately, common commands relating to them) that seem unrelated actually vitally affecting each other - this is why typelib has become something of a monolithic monster.

This isn't a problem with ALAN, because basically all the player commands and syntaxes are defined in the library and it is therefore very easy to override and re-use them object by object exactly as required. Quest however has a lot of the standard commands 'built in' which makes them easier to use as they are, but means that overriding them for a specific class of objects is a rather trickier exercise.

It's still possible to do Quest Libraries in a modular way, just not entirely practical a lot of the time Discrete functionality like vehicles and combat which probably don't have any overlap with the object types added by typelib could certainly be done as separate libs.

Typelib does have a 'scenery' object in it by the way, I use it for the Swimming Pool in the demo piece where it allows you to examine etc the Pool object though that isn't actually 'listed' in the room.


Al (MaDbRiT)

That's a good point about overriding the built-in behavior. I noticed that in the integration of your lib with the Quest environment there was considerable contention between the two.

Would it be worth asking Alex to consider offering an override feature to the built-ins that would allow them to be replaced? Then, if the user has a lib that would handle his particular task in a more specific fashion, it would supercede the default behavior. For example: The Quest system would work just fine with a space themed adventure. But, suppose that the user had available a lib that contained objects that were specifically space-oriented. It could supercede the built-in finctionality of the generic object. That may be an oversimplification. But, it might be just as simple as showing all the built-in objects in a list, and letting the user select the one(s) that his lib replaces. The default would then 'disappear'.

Or, maybe in the user lib there could be a way to put a "replaces commandABC" or "replaces objectABC" to tell the system not to process the default object or command AT ALL.

Your opinion?

Alf

Hi Alf

That's a good point about overriding the built-in behavior. I noticed that in the integration of your lib with the Quest environment there was considerable contention between the two.

Would it be worth asking Alex to consider offering an override feature to the built-ins that would allow them to be replaced?

The overrides do exist, what complicates things is how integrated everything is. By way of example take a containable object from my llibrary.

It needs the default take behaviour as built in to allow it to be taken when sitting in a room - but obviously a DIFFERENT behaviour whan it is sitting in a container which is in the room, where "take" really becomes "take from". Of course because it isn't listed in the room (and we wouldn't want it to be) the standard take can't find the object...

"LOOK" is the same, a standard look command is fine if the object's in the room, but will fail if it is in a container which is in the room. This also affects 'examine' in the same way. The various GIVE options also have to be replaced as do the DROP options, then you have to add the put in and take out possibilities. USE is also affected in the same way.

Basically, for many of the 'types' in typelib I pretty much have to provide custom versions for all the standard built in commands that combine standard behaviour and custom behaviour as required. Because I still need the built in commands to work exactly as before for other objects that are NOT typelib types or I'd break QDK, this means I sometimes have to look for ways to make things work that might not be the most elegant or straightforward, but which dovetail nicely into the Quest/QDK model - something over which I have no control.

This isn't actually an insurmountable problem, so far I've been able to find a way to make every kind of object I've ever needed in Quest, which says a lot for how flexible the system is. What I've found is that I have to produce very detailed objects for QDK to be much use and that it's very hard to write these without a lot of crossover. Take the Clothing type, it also needs to be a containable, it introduces yet another variation on 'take' and 'drop' in addition to those required for ordinary containables and ordinary objects, being clothing it has other requirements (wearing in layers etc) all of which impact on ability of the player to 'drop/take' it - and so on and so on...

To be fair, Typeplib isn't as QDK friendly as it could now be, pre dating as it does a lot of testable conditions that would allow far more elegant solutions to be coded in a re-write. However, as I see it, the basic situation remains that because it is inherent in the way QDK/Quest work, the ideal of completely modular self contained object libraries of any consequence is likely to be very difficult to achieve.

While that makes things a bit more difficult for the library writer, it tends to make things a lot easier for the QDK user, so perhaps that is a good trade off.

Al (MaDbRiT)

I see your point. I'm still looking at things from a pure object environment, where each object 's properties - including location - can be determined programmatically. (Hmm, maybe that's THE answer, making everything into objects with properties ).

Thanks for the chat. Always very interesting!

Alf

Alf wrote

Hmm, maybe that's THE answer, making everything into objects with properties

Believe it or not, this was exactly my intention when I first started 'typelib' - the idea was that the end user would ignore QDK's default object panes and program his/her whole game using objects based on my 'types' - which is of course another way of saying using just objects instantiated from my 'classes'.

(Look at typelib_2 and you'll see it does exactly what you are suggesting, typelib's objects have properties and 'actions' (a.k.a. methods) that attempt to put all functionality into the object itself as much as possible.)

Had I been able to achieve my intention, it would have avoided a lot of the problems which centre around making the mix of my types and Quest's default objects co-exist.

Unfortunately I quickly found that you can't actually enforce the use of the types I added. Although I provide a regular (optionally takeable) object type as part of typelib, QDK will always let people define objects that are NOT derived from one of my types and so I'm obliged to cater for all the possibilities that opens up.

This is exactly why having all the default objects & related commands defined in a library rather than internal to Quest appeals to me - under those circumstances I could simply replace the default structure entirely rather than have to work around it.

Whatever, nothing is perfect and I still really like Quest and will continue to try to find ways of adding easy to use functionality with libraries of code. These libs might not always be easy to write, but that's rather less important - the whole point is that the intended end (QDK) user need never know what sort of hideously inelegant bodge is going on under the hood to provide those nice easy to use objects.

Al (MaDbRiT)

typelib_2? I don't think I've seen it, have I???

typelib_2? I don't think I've seen it, have I???

Err, no you haven't.

it's the successor to typelib which seems to have 'stalled' in pre beta release form due to:

a: My being unable to 'feature freeze' it - I keep adding things which push the whole thing back to 'development version only' status. Entirely my fault, I know I ought to leave stuff out until "typelib 3" and get this version de-bugged, but I am by nature a perpetual code-tweaker.

b: My knowing that, with recent improvements in testable properties and actions being added to Quest (thanks for listening Alex!) I could do a lot of the stable working stuff brought forward from the original typelib a lot more elegantly now. I know I ought to do it, but every time I look at those 3000+ lines of code I just shudder at the thought of pulling it all apart and re-writing it when it already works...

c: Real Life getting in the way of important stuff like playing with Quest

For the record, main differences in typelib_2 compared to typelib are:

Far better NPC interaction. NPC''s can wear the layered clothing, be instructed to do things that the player might otherwise do himself (take, drop, examine etc can all be directed to NPC's now)

e.g.

"Fred, put the widget in the fridge"
"Ask Fred to examine the suspect parcel"
"Fred, take off the Tutu"

All work as you would hope. as you can imagine theres a lot more 'stuff' required code wise to make this happen.

Other 'big improvement' (at least in my opinion) is the provision of a 'topic' type that allows an object, player or room to become a topic of conversation - easiest way to demonstrate this is with pseudo game output, using "TLT_topic" the following is possible without writing any new actions or conditional tests:

>Ask Fred about the car
"Sorry, I know nothing about that"

>Ask Sue about the car
"It's mine, a Porsche 911 - it's nice isn't it."

>Tell Fred about the car
You tell Fred all you know.

>Ask Fred about the car
"It belongs to Sue, I'm told its a Porsche"

>ask Fred about Sue
"She's a nice girl, bit of a speed freak I'm told."

>ask Sue about herself
"I'm a librarian, but I do have a thing about sports cars".

a few well placed 'If-Thens' and this "conversation" can be expanded to make for pretty good almost realistic effects. The thing to note is that Fred apparently 'learns' by what you tell him - and Sue describes herself differently than Fred describes her - this is all inherent in the topic type.

Al (MaDbRiT)

Wow, talk about some nice features!

The character interactions (in my opinion) add depth to an otherwise OK adventure. Also, the NPC options make for a more realistic play. So much more than the early IF games which made you feel more like a programmer than an adventurer.

Already, I'm thinking about the possibilities. Walk into a room, and one of the NPCs come up to you and offer you something (drink, advice, etc.). You head off to another location, and find the same NPC beat you there because they knew the short cut.

As I've said before, the best IF games do not need graphics. They allow the avdenturer to bury themselves in the game. Now, all we need are good IF game writers...

I still wish there was some way to totally override a default object or behavior. That keeps the user in step with the world you're creating.

Thanks, Al. Keep me posted on the new lib!

Alf