* the ability to match an icon to an ASL file
* templates and/or game engines that come with the release
* extra commands such as SMELL, HEAR, PUNCH, TOUCH, EXAMINE, STEEL, etc
* a user-friendly map
* hotkeys (like somebody else suggested) ie. keys that when pressed will access a picture/execute a command etc
* make changing the colour of text a whole let easier by incorporating that into QDK

quote:

---

* the ability to match an icon to an ASL file
* templates and/or game engines that come with the release
* extra commands such as SMELL, HEAR, PUNCH, TOUCH, EXAMINE, STEEL, etc
* a user-friendly map
* hotkeys (like somebody else suggested) ie. keys that when pressed will access a picture/execute a command etc
* make changing the colour of text a whole let easier by incorporating that into QDK
* a command that restarts the game

If anyone else in this forum has any ideas, don't hesitate to reply to this topic....

---

Point by point:-

Well you can change the icon associated with an ASL file through Windows Explorer, but of course the Icon used will be the same for every ASL file, the whole idea being to associate the .asl extension with the Quest Engine.

Not sure what you mean by templates or game engines with the release. I tend to think of templates as part of the game creation process and the game engine as an entirely seperate beast. Is this not two rather different points?

Anyways, some talk on here about having a facility for a compile to executable version, so I'll comment on that.

There's no real point. The finished 'exe' would be pretty much the same size as packaging the current Quest Engine and game as seperate components, so nothing to gain. It would result in duplication of a lot of code on everybody's machine - a bad thing. ( The exe would still need the rather bulky VB runtimes and so on regardless of how it was packaged.)

If you want to distribute a game with all you need to play it, I'd suggest simply including a copy of the standard Quest shareware install with your game specific files. A brief note explaining that those who don't already have the Quest Engine installed will need to install it before double clicking your game's ASL/CAS file to play would cure the problem. I'd also make sure that you offered a version of the package without the Quest Engine for those who already have it.

It's probably as well to remember that ALL the adventure game engines use this seperate run engine and game files approach so it is accepted practice anyway.

Extra commands.. such as Examine and so on.

Well Examine was a glaring omission and that IS internally dealt with in Quest 3.0 so I'm sure that will please you. :-) The others though are prime candidates to be added by the user, ideally in the form of an includeable library. I'm working on an extension library for Quest 3.0 and I can certainly add the simple code required to facilitate the other senses ( hearing, taste and smell ) without any problem if anyone else thinks it would save them a little work :-)

Mapping - I assume you mean in the style of ADRIFT here, is a little more tricky to do. I don't personally like the idea anyway, but that would I suspect involve a lot of work for Alex. If we had a game resource where we could bundle our game files and have them secure from the player it would be easy to do with simple 'show' of a graphic file from within the current Quest system. I personally think that would be a generally more important improvement than a map as such.

Hot keys.. well that is simply a question of programming a command - unless you mean an abilty to use the Function Keys or action created without a return/enter keystroke?

Changing Text colour within QDK I guess Alex could make a dialog box for doing that, but as I don't use QDK much I really don't see that as a big problem. If you use a text editor as I do, the current way is actually very effective. A pity Alex didn't use html or UBB code style though, that might have been a little more familiar. I do realise that HTML is out of the question b.t.w., Quest uses the tag delimiter symbold for other purposes.

If you want to force a restart from code, (you can already do it on the Quest Engine's menu system of course) using a 'lose' to kill the player is an effective way of bringing up a 'do you want to restart/quit' dialog.

Say I had a picture, QDK would open this and ask "Where, on the map, is this room located?" You would then draw out the area on the map. Then when you looked into the map, Quest would open the picture up, look into the quest.currentroom, see which room it is and change the area a different colour!

..... so basically you are defining area's on a picture to different room's, and quest changes the colour of the area..... got it?

I don't have any real issues with the other points Carlii made........ commands are MEANT to be made by the developer...... it's what gives us versability!

Icon's to ASL files??....... you must be making your own! I'd just use a short cut myself! Have a shortcut to the ASL file and have the icon defined there!

Colour changes...... not a problem either! The only reason I'd use that is for the puzzles, to make things clearer!.... and maybe BEWARE in red letters. I'd put more concentration into describing the world, making the game easier for the player and things like that.

I still can't wait until Alex put's in the saving capability...... so then my flash interactivity can start! :)

quote:

---

I would use flash to personally do the map.
With it's versability you would have one picture for a whole area and move the dot (to show your location) about using the variables. Now with the different pictures idea, you would have one picture for the area and your location. Then another for a different room, then another for a different room...... With Flash you could have an arrow, suggesting the way you are looking, one map/many maps, a zoom function and many others that would be quite good..... of course not many people would have flash, but still, I don't see having MANY pictures as a good idea! Personally I wouldn't mind if Quest used a form of this.

Say I had a picture, QDK would open this and ask "Where, on the map, is this room located?" You would then draw out the area on the map. Then when you looked into the map, Quest would open the picture up, look into the quest.currentroom, see which room it is and change the area a different colour!

..... so basically you are defining area's on a picture to different room's, and quest changes the colour of the area..... got it?

---

I don't see having to have many pictures depending on what room you are in is a great solution either, but then again I think using Flash is a pretty bad idea as well. Why? To use your own words:-

quote:

---

"not many people would have flash"

---

I simply do not like the idea of any game that requires some other software being present on the user's system as well as the game engine - unless it is absolutely SURE to be present (like say a Win 95/98 standard feature) it will prove to be a complete pain in the neck to most users. Using proprietary software like 'Flash' is just about the worst case scenario to my mind.

I personally think that if you are going to have this map feature it needs to be done WITHOUT forcing the player to install some other software somewhere along the line.

I admit I intensely dislike Flash and all products of it's kind, finding it deeply irritating when I hit a website that tries to force me to download yet another blasted plug in - I usually just skip such sites - or at least the time hogging Flash like parts, so I'm pretty much sure to feel this way on this issue - LOL.

Another point is that you really need the map to only show the rooms the player has visited - unless you want him/her to have a God like pre-knowledge of your game world. That really suggests you have to track where the player has been inside Quest and translate that to a map.

Using Flash (or something like it externally) would surely means passing a lot of data to an external program in some way and currently that can't actually be done with Quest at present. Although mapping using lots of pics is a far from ideal situation at least it actually can be done - if you see my point!

Of course, if Alex adds a mapping feature to Quest like Adrift has, that is a whole new ball game, but speaking purely personally PLEASE don't write a game that means I'd have to have software x, y or z in addition to the Quest engine to play it - that would annoy the hell out of me!

The only way I'd find 'additional software required' games acceptable is if the software could be distributed with the game that needs it and I don't advise you to start shipping proprietary software with your game unless you have a damn good lawyer!

quote:

---

I don't have any real issues with the other points Carlii made........ commands are MEANT to be made by the developer...... it's what gives us versability!

---

I agree entirely with this, but I don't see the harm in having commonly used extra functionality available as an add in library, there is little point in re-inventing the wheel.

quote:

---

Icon's to ASL files??....... you must be making your own! I'd just use a short cut myself! Have a shortcut to the ASL file and have the icon defined there!

---

That would work... especially if you were bundling the whole game with a Quest shareware version install kit. :-)

quote:

---

Colour changes...... not a problem either! The only reason I'd use that is for the puzzles, to make things clearer!.... and maybe BEWARE in red letters. I'd put more concentration into describing the world, making the game easier for the player and things like that.

---

I tend to like to use colour to denote specific things, for instance if a character is speaking to the player, printing the character's words in a distinctive colour / font can help readability. This is something to be used sparingly and only when you have a specific policy such as that I just described, careless overuse of colour / font changes just hurts the eyes.

quote:

---

I still can't wait until Alex put's in the saving capability...... so then my flash interactivity can start! :)

---

Probably the only one who'll say this, but I repeat - please don't do it! I really don't want to find every other Quest game that comes out requires me to go track down and install (even pay for - God forbid!) yet another piece of software I don't already have.

Al

I know that this player is built into the later generation browsers, all Win 98 or later PC's have it and even AOL installs it by default these days (as part and parcel of Shockwave installation).

There will still be a lot of people on older Win95 m/c running IE4 or previous.. these are the people who I was thinking of in my earlier post - but I didn't make that very clear!

for a feature, what about this - extending the beforeturn and afterturn functions, so that there can be a before and after function for every room, object, and character in a game.

This would save a lot of worry about the order of executed script, by making it possible to put the code that is executed everytime a room (object, whatever) is used in one place.

Other than that, for features i just think it is better to keep the philosophy of simple and general features, rather than filling the system with specialized features only used in a few places each.

Doing that to make a system easier to use is self-defeating, because the larger the number of features, the harder it becomes to learn them all, and the more effort it takes to divide up a problem into parts that can be executed.

So if you really need a whole heap of specialized functions, i'd put them in libraries, not into the language.

Al:: I do understand your position, I myself have Win95 (I didn't feel like upgrading!) and IE5. Now the first thing I thought of, when I came up with the idea of putting Flash 5 with Quest games was "I want ALL my players to be able to run it!". As a feature of Flash, you are able to export it in .exe form, a "projector". This way it comes in a small .exe and is able to run straight off. It is easier to shell and doesn't need the player to install anything extra! I would never dream of having something that needed the player to install software after software just to play one game, PLUS I'm giving the player the oppertunity to choose, if they want all the extra sounds, pictures (there might be 1 compulsary... that is all I would expect!) and flash things then they will have to download an extra ZIP.
As for your dislike for flash, I share it for web sites (if it is in excess ONLY). I only have a 28.8k modem and a 120Mhz PC. Once I get a better PC, I'm going to mainly use this one for Quest stuff, having it online 24/7 and running QX3!! :)
You say that there's no point re-inventing the wheel...... well that would be true, but what about people that go off doing things that were done 100 years ago? They do it for pleasure, the pleasure of acheving success. That's why I'm doing alot of my own stuff, it's not the easy way, or that it's better. It's that I get a sense of self acheivement, that I get a grip of how my games work, that I know all about my games inside and out!
Yes you were right in saying colours can be added in moderation....... I agree. If you have three options in a puzzle, and it has:
Red, Blue or Green switches? And you have the words in their colours (Red in red, ect..) then that would be clearer to the gamer..... also my example of a WARNING sign was a valid exception IMO.
I AM going to have Flash interactivity with Quest when it becomes available, BUT you will have the option of not having it (for space, ect..) because I believe it is the gamers choice! It WILL be self-runnable, and any other inclusion's will be software free.

Tyrant:: I too have been thinking along the lines of FMV sequences with Flash...... just because the interactivity isn't an option, it doesn't mean I can't have fun! I'm just going to start making story-board type picture's before I do anything, I've got one HELL of an idea though...... hehehe, it'll be GREAT!!! Unfortunately I haven't been fooling around with the shell command much lately, I'm just waiting until Quest 3.1 (or whatever) with QDK 3 comes out, then I'll see if it works!

passerby:: Now I don't understand what you mean?? You say you want to add in to the after turn function, but the after turn function goes through-out the WHOLE game! Why have it specific for room's? And you can right now anyway, you just need to add:
If player is in #room# room" and do a then, and else. It's really basic. I don't understand that you want the specific to OBJECTS??? huh? Am I missing something here?

quote:

---

for a feature, what about this - extending the beforeturn and afterturn functions, so that there can be a before and after function for every room, object, and character in a game.

---

Quest 3 already has the afterturn / beforeturn functionality available for every room as well as the global one... so Alex has pre-empted this part of your request ;-)

quote:

---

Other than that, for features i just think it is better to keep the philosophy of simple and general features, rather than filling the system with specialized features only used in a few places each.

Doing that to make a system easier to use is self-defeating, because the larger the number of features, the harder it becomes to learn them all, and the more effort it takes to divide up a problem into parts that can be executed.

---

I couldn't agree more. This "bundle everything we can think of into the standard engine / library" philosophy is one of the things that makes TADS so damned hard to learn for the beginner. Of course it also adds pointless bulk to games too if there is a mass of code that never gets used included in every game!

quote:

---

So if you really need a whole heap of specialized functions, i'd put them in libraries, not into the language.

---

Again - agreed entirely! If anyone else here is familiar with the ALAN library system, I'd suggest that it is a great 'model' to base library development on.

For those who don't know, standard features aside, ALAN's library is supplied as a whole bundle of individual skeleton modules, so the author only has to 'include' the bits he or she actually needs for a specific feature - obviously some really basic features are interrelated, so sometimes you need to use a few modules that are not obviously directly related, but this is a neat way to cut down the size/complexity of game code.

My own libraries for Quest 2.x use this philosophy, rather than build 'vehicles' and 'elevators' into my general purpose 'standard.lib' I implemented them as entirely seperate libraries for instance.

I think this has got to be the best approach. :-)

Computer Whizz::Why i want before and after functions for each Room, Object, and Character in the game:

i think i can best describe this using beforeturn/afterturn as examples - they are used to execute code that is not triggered by a player action EVERY turn, and i know it. This is useful for many things.

before and after would work similarly, but are used specifically for one room (or object, etc).

This is good if you have code that will be executed for whatever the item is, regardless of what the user does with it (simple example: counting the number of times a user enters a room, or handles an object).

existing beforeturn/afterturn could do this, yes, but it involves a bit of fudging (using the 'if' in your example). This is easy while you only need to do it a few times in a game, but when you have a large number of items, rooms, and characters with individual code not connected to player actions, your code becomes a mess, and it complicates the code without adding anything to the game.

I wish i had an example to show you, but unfortunately i don't.

MaDbRiT:: You already can use before and after functions for rooms? i could'nt find that in the help files, could you tell me how it's done?

quote:

---

MaDbRiT:: You already can use before and after functions for rooms? i could'nt find that in the help files, could you tell me how it's done?

---

This applies to Quest 3.0 only:-

I've not used it myself, but you can apparently have both a beforeturn and afterturn defined within each and every room block. An optional 'override' clause will prevent the global beforeturn / afterturn from running in addition to the local one(s). Look at the section on 'Room Definition Blocks' in the ASL manual.. on the pdf version I produced it's page 18.

quote:

---

And i had another idea. What about making connections between rooms, objects, and characters entities themselves, so that code can be attached to them? This would make it easy to, say, disallow an exit while it is blocked off.

---

That's an 'Inform like' construct if I remember correctly. And it is a perfectly valid way to go. I rather think that a simple way to 'uncreate' the exits as required would be easier to implement in Quest though.

I've not tried to do this, but I have a feeling that you could actually do the 'exits as objects' idea within Quest as it is, by defining a 'door object' type and popping one in wherever it was needed - the only real issue would be keeping the compass buttons accurately reflecting the exits.

I've noticed that there's still a lot of mention of coding 'characters' and 'objects' in discussions of Quest 3.0.

Unless I'm mistaken, in Quest 3 'characters' are only really supported for backwards compatability. I think the idea is that seperate characters and objects are now intended to be replaced by the one combined 'object' model. This means objects now support the 'speak' tag etc. etc.