Was just wondering if there is a limit on the amount of libraries one can include in an asl file. I'm thinking of lib'ing everything into manageable chunks. Each NPC has their own qlb file. All items are in a GAME_Items.qlb file, etc. Is anyone else doing this?

There's no theoretical limit on the number of libraries you can include in your game, though in practice it will be limited to 32767 (as with most things in Quest - and nobody has ever come close)

Thanks. I couldn't come close to that limit without getting a little more than scared. I've only got two hands.

I'd specifically like to know if anyone else is employing the following method:

1) Include all resources in separate qlb files (IE, Startscript.qlb, Types.qlb, Commands.qlb, Procedures.qlb, Functions.qlb, Items.qlb, HelpFile.qlb, Afterturn.qlb, Beforeturn.qlb, NPC_A.qlb, NPC_B.qlb, Rooms.qlb)
2) Populate objects throughout rooms with Startscript.qlb
3) For item objects: clone and populate mutiple copies to the same room and/or multiple rooms via same Startscript.qlb

Is this common practice? Or do many of your just keep your script in one large file?

Secondarily - and I haven't trudged through this yet, mind you - I'd like to know what anyone's approach to conversations has evolved into: menu-based, keyword-based, etc. and why.

Nice. A man who has done seom thinking.

I prefer to keep libraries subject-ional.. IE, an RPG fighting library. A shop library. A Spell library.

Game-specific things such as startscripts I prefer staying in the one file - but I would guess it'd be quite nice. Having hot-swappable files to create a slightly different/harder/whatever game (putting objects in certain places at startup for instance).
Nice idea to think about.

Conversations. I'd guess keywords would be the nicest/best.
It allows a much better flow of the game, and also gives you and the player, the freedom of varying conversation streams.
While, with menu's, you are locked into certain paths. It can also have NPC's learning about things if you so wish - without have to program each little bit into a menu.

Tr0n,

Could you elaborate on the learning aspect of a keyword-driven conversation implementation?

Now I know keywords can limit PC characterization, while menus can elaborate on it. IE:

Keyword = ask harry about sally
Menu = 1. "Sally's a bi*ch. What do you think?" 2. "Oh man, that Sally. She's great. Any thoughts?"

The keywords are easier for scripting purposes. The menus are better for allowing the player some control over the PC's personality.

Scrolling through some old posts, I found an interesting take on keywords by a fella' named "I think Im Dead" (apply index and middle finger to jugular, wait for pulse). http://www.axeuk.com/phpBB2/viewtopic.php?t=109

Or keywords can also be:

> ask harry about sally
Harry replies, "what's your opinion of her?"
> respond I think she's cool
Harry replies "I think she's horrid myself!"
Harry adds, "I've also heard that she's been lurking around the back of Joe's motel late at night. Isn't that where the murder took place?"

Keywords basically pick stuff from the stuff you enter in. So you COULD pick out 'bad words' - or even have the game itself learn those words to make them good/bad.

And having characters learn facts is easy - especially if those facts are properties. Since you can just give a character a propertie/fact.
Simply make a command along the lines of "tell Harry about Killer".

It just requires more programming - that's all.

Gotcha.

Each NPC extends their 'flat-file' database of properties to include ones that denote specific pieces of information. This could then in turn affect their normal behaviour patterns.

------------

Well. Quest is pretty easy to use. I'll beg the wife for her credit card.

------------

Anyone working on anything interesting?

Sort of.. yes.

Unless you plan on using QDK alot - or turning games into CAS files (encrypted and media-combined files) then you don't need to buy Quest.

I may buy a licence for QuestNet Server later on - but not right now.

I don't QDK. It took a while, but I think I've got code-eye for ASL now.

But I'd like to encrypt what I create. Knowing that someone has completed a game without "cheating" would be much more satisfying than the inevitable alternative.

Not that I wouldn't want to contribute to the Quest community: I'm attempting to build a model with ASL from which I can produce games quickly. I'd like to share that. Nothing too complex, mind you - I'm slowly becoming a blue-blooded realist. I'm taking a modular approach, so that 'hot-swapping' thought of yours does come into play.

What are you working on? Or perhaps I should just review your gabillion posts?

Not working on too much right now.
Ever since I ran into a problem with Quest's integer limitation in my RPG library, I just had to halt it.
I'm going to do a little work on some demo's, all revolving around the same sort of 'theme'.
But hopefully, I'll be able to work on my version of Quest - a simple cross-platform console-based (C++) program.
It will hopefully support ASL 2.17 onwards or whatever - might have to limit this to 3.0 onwards. But it's nowhere near complete; only just off the starting blocks.

I do have 3 games in my brain. One, a final-fantasy-esque game. While number 2 is a true adventure game (to become a series) and another jokey-adventure game (if you've ever played Ditch Day Drifter or Unkoolian Unventure 1 / 2 then you know what I mean).

I don't have the time to do much right now - and I want to do the minor things first - library etc. So I'm holding off.