Static quest API

Ronan · Post by **Ronan** » Sat Sep 02, 2006 5:17 am

We need a framework to help make static quests easier (journal entries, and all that). This is probably pretty easy, but the more we take off the builder's shoulders the better. I think bartleby wants to help with this?

There might be stuff on the vault as well.

bartleby, lemme know how much you've thought about this, and what other systems you think it might need to interact with.

indio · Post by **indio** » Sat Sep 02, 2006 5:38 am

Bool and I are working on a system that utilises the auto-quest system I integrated into the original basemod, but with some significant simplifications and customisations.

Here's how it works:

Think about the type of quest you want to create...get this object, convince this person, fight this creature....the important thing to recognise is that requiring an object to retrieve is often quite limiting (and this was probably the achilles heel of the original system). Stored variables are much more useful for ensuring flexibility, although items in inventories are fine also.

- Make a copy of the appropriate NPC Quest Template (there will be 4 or 5 types of NPC, each geared with quest types)
- Customise the variables on the NPC to add the following:
1. Give the Quest a TAG
2. Use that TAG in the Journal for persistent journal entries (start and finish entries only)
3. Add what the NPC says to give you the quest (when they do so, your Journal is updated)
4. Add the TAG/S of the item/s needed to be acquired, or the TAG of the NPC you need to speak to, or the variable name you need to have carrying, or whatever else Bool and I can come up with
5. Add what the NPC says when you have returned meeting the criteria
6. Add the XP gained, gold rewarded, or item given

The new dimension is this...we are adding the ability to talk to a new NPC who will only respond once you have been given a quest. What this allows is the flexibility to add any type of quest as you are no longer limited to 'return with the orc's head'. Instead, you might now return with the orc's agreement to leave the vicinity.

I'm also trying to figure out a way to create a generic conversation that relies on variables to introduce quest-specific conversation, but that is essentially a matrix of skill checks. Essentially the outcome of the conversation would be about relying on whatever skills you actually possess, ensuring that the diplomats have a far greater chance of resolving conflicts without resorting to violence and being rewarded accordingly.

ANyway, it needs to be finished (should be within a week or so) so anyone interested can take a look. All credit for the auto-quest system goes to the Vault author of the work.

Ronan · Post by **Ronan** » Sat Sep 02, 2006 7:24 am

Hmm. Well, I admit I had a different system in mind, using the custom events system. It would be a lot more flexible, mainly since the custom events system is so flexible (though its currently very incomplete, and may remain that way).

Basically, in my mind most or all quests can be thought of in a relatively few number of states (or steps, basically, with corrisponding journal enties). So we should give builders easy ways to track and change what state a PC's quest is in, whether through conversation, the death of an enemy, acquisition of an item, etc.

indio wrote:I'm also trying to figure out a way to create a generic conversation that relies on variables to introduce quest-specific conversation, but that is essentially a matrix of skill checks. Essentially the outcome of the conversation would be about relying on whatever skills you actually possess, ensuring that the diplomats have a far greater chance of resolving conflicts without resorting to violence and being rewarded accordingly.

Thinking about this, I'm not sure you'll be able to do this in a reasonable manner, compared to just making a conversation for each quest. I think it would also be a lot easier for builders to work in the conversation editor than any API setting variables. NWN2 will simplify conversation scripts a bit, by allowing arguments to be passed to them. In other words, greatly cut down on the number of conditional scripts needed.

Oh, whatever ends up being done, I think you should definitely considering adding location (trigger?) based events as well. For patrols and the like.

indio · Post by **indio** » Sat Sep 02, 2006 7:42 am

It's fun developing the auto system so I'll continue with it, but I would love to hear more of what you've got in mind. The auto-quest system removes the need for creating scripts when questing, and conversation files. It's all just variable modifying.

So if you've got a fully-fledged Quest System in mind, something to help organise large quests (as my system is almost exclusively geared for single fire static quests) then I'd love to work on it with you.

I've done a lof of trolling over the vault quest systems. I'll try and make some comment on them over the weekend, as I've tried a few.

Ronan · Post by **Ronan** » Sat Sep 02, 2006 2:17 pm

Ah. My idea is more based off of using scripts, but simplified well-documented scripting. And its for quests of any size really, where the PC's progress in them would be saved over module resets and such.

indio wrote:I've done a lof of trolling over the vault quest systems. I'll try and make some comment on them over the weekend, as I've tried a few.

Please do, I know nothing of them.

peterdin · Post by **peterdin** » Sat Sep 02, 2006 3:12 pm

pfff...

I'm triggered by the renark of ronan about the eventing system.

Essentialy a static quest can be considered as a state diagram where the state transitions are caused by acts on a NPC
acts can be one:
- talking
- damaging
- receiving objects
- giving object
- etc..

I know there are statediagram translaters outside that translate diagrams into code.
What the scripter has to do is setting up this diagram and then allocating the right events to a certain NPC.

but anyways.. I have only thougt a bit on this, dont have to time to work it out, but I thought to share it anyways..

Ronan · Post by **Ronan** » Sat Sep 02, 2006 3:33 pm

peterdin wrote:Essentialy a static quest can be considered as a state diagram where the state transitions are caused by acts on a NPC

Exactly what I was thinking, I just thought using terminology like a state machine might confuse some people here unfamiliar with it.

peterdin wrote:I know there are statediagram translaters outside that translate diagrams into code.
What the scripter has to do is setting up this diagram and then allocating the right events to a certain NPC.

Now that I did NOT think of. Do you think there are any which could be easily modified to work with nwscript?

Fionn · Post by **Fionn** » Sat Sep 02, 2006 3:50 pm

Are we talking reuse of some stock scripts/convos to make scripting a quest easier for builders, or some system that can be 'scripted' via Word or Excel? I'm all for time saving and reuse, but I'm not sure if it's worth it to make a system that requires no understanding of the engine. Essentially, we should assume that anyone implementing such things will have a minimum level of knowledge (or be in process of gaining it).

It might make sense to include in that documentation a simple Word or Excel template that allows [OP] to design quests that a builder can later implement.

peterdin · Post by **peterdin** » Sat Sep 02, 2006 7:09 pm

Ronan wrote:
peterdin wrote:Essentialy a static quest can be considered as a state diagram where the state transitions are caused by acts on a NPC
Exactly what I was thinking, I just thought using terminology like a state machine might confuse some people here unfamiliar with it.

peterdin wrote:I know there are statediagram translaters outside that translate diagrams into code.
What the scripter has to do is setting up this diagram and then allocating the right events to a certain NPC.
Now that I did NOT think of. Do you think there are any which could be easily modified to work with nwscript?

They generate C++ code, so it might work. I'll check (but I have to dig deep)

found it after some searching on the net here:

SMC - Finite State Machine Compiler (C++) http://www.objectmentor.com/resources/d ... in/smc.zipThe C++ download is the source code for a simple compiler written in C. It translates an ASCII description of a Finite State Machine (FSM) into a C++ program. The generated code never needs to be touched. Rather it inherits from a class that the user writes. (text format)
doc can be found here:http://www.objectmentor.com/resources/a ... umlfsm.pdf

And for fions post: it doenst work outside word/excel.
You'll still need knoweldge of the toolset and probably some programming understanding, I dont know how easy would be at the end,

indio · Post by **indio** » Sun Sep 03, 2006 3:23 am

4 noteworthy ones:

EQMM - Efficient Quest Management Module
http://nwvault.ign.com/View.php?view=sc ... ail&id=528

EQMM makes quest management easy AND efficient. No longer wasting space storing integers manually with Get/SetLocalInt. EQMM stores these informations using bit arithmetic, saving space up to a factor of 16!
EQMM lets you easily check if a player or the party has all items for a quest AND is much more efficient than using the BioWare functions CheckPartyForItems or GetItemPossessedBy (details within the file).
You can also find out which items are missing and tell the player this in a conversation, CustomTokens will be set for you automatically!
New version 1.5 out with some other goodies implemented, like removal of quest items, counting items (for bounty hunter quests)...
Now with Windows Help File as additional documentation.

Conversation Editor System - William Hughes
http://nwvault.ign.com/View.php?view=sc ... ail&id=325

A conversation script system that takes advantage of the variable system added in the latest patch to drastically simplify starting conditionals and actions taken in dialogue trees. Includes README and documentation.

Bitwise Quests and Tasks system
http://nwvault.ign.com/View.php?view=sc ... il&id=2665

The Bitwise Quests and Tasks system is fundamentally a set of functions that assist new scripters in organizing and creating their quests while impressing experienced scripters by using binary techniques to cut down on the number of integers that need to be stored to make a functioning quest. The ratio of this consolidation is 31 Quest States to 1 Integer, where each quest state is basically a 'Yes or No'. The BQT System has now reached version 1.7, which fixes a very critical bug discovered by jingleheimer. If you were having trouble getting the BQT to work correctly, it should function properly now. I'm sorry that this problem existed as long as it did but I'd like to remind everyone that if something doesn't work, you need to let me know about it because I honestly didn't realize that there was a bug. Besides bug fixes, the BQT's most used functions have been rewritten to be sleeker, and 3 new functions have been added. With version 1.6, the BQT has become much more than the fundamentals. This new release adds support for the NWNX Database Alternative, persistent journals, a new user include to make new updates easier to import, two seperate types of party functions, bug fixes, automatic cacheing to reduce read times, and finally tutorials and script templates to walk even a non-scripter through their first quest and the tools to easily make more.

With the BQT, it's easy to bring your world alive, having townspeople congratulate your heroes on all of their good deeds while shunning away from villains who've become infamous for their greed. Without memorizing any NPC tags or stuff like that, quickly and easily write a new quest and let everyone in town know about your deeds.

So take the work out of making quests so you can take more time fleshing them out and making a great world.

The MSI Quest System
http://nwvault.ign.com/View.php?view=sc ... il&id=2401

The Moonshae Isles Quest System is a fully customizable quest creation system that makes use of data structures to hold the parameters for the quests. Builders can set alignment, class, and race limitations, gold and XP rewards, items required to finish and start, items given at finish and start, time requirements (hour of the day), and much more. Support for NWNX2, Bioware Database, Info Holder, and Local Variable data holding. Examples included. See documentation and scripts for more info.

Bitwise may possess the most promise in terms of the recent update status (still a year ago), but there's merit in all of them. I personally like William Highes' concept, and he has made some excellent modules.

peterdin · Post by **peterdin** » Mon Sep 04, 2006 8:43 am

looks promising. needs some invest though.

As these are already existing solutions I would go for one of these

ç i p h é r · Post by **ç i p h é r** » Wed Sep 06, 2006 2:13 am

You might want to add Baalster's quest system to the list (a working version is in the White Horn module I believe and documented too!), described here:

http://www.alandfaraway.org/phpbbforum/ ... hp?t=27827

Also, I remember Grey Pilgrim (I think it was him) talking about substantial improvements someone had made to the current basemod quest system, but unfortunately, my recollection fails me. Still thought it worth mentioning if you're looking to examine these systems.

indio · Post by **indio** » Wed Sep 06, 2006 3:22 am

Yeah, Baal and I have discussed it a bit.

He took the auto-system we put in the first basemod and added a reputation dimension and some other functionality that I've been looking at in the WHitehorn module. I figured I'd leave Baal's Rep system to be integrated separately into the basemod and then retrofit the auto-quest system with it once it's all stable.

Welcome back. I'm running really behind with testing but I'm going to be relying on a 2 week holiday I've got coming at the end of next week.

Baalster · Post by **Baalster** » Sat Sep 23, 2006 10:29 pm

The script-less quest system which was in the original base module was too limited in terms of writing complex dialogues for the questgiver. I hate having simple sentences which gives the quest designer far too little to work with. The idea of having a set of scripts that we just attach to the converastion on misc nodes is better in my view. Just by making a few samples and tutorials, people can make their own quests in minutes. Or the DMs can submit the quest described in a particular format, then someone who's more skilled can add the quest properly.

Unless we can have a dynamic dialogue, I don't see the use of a system where the dialog is token based taken from a local variable. It's too limited.

Baalster

Ronan · Post by **Ronan** » Sun Sep 24, 2006 10:37 am

HDM-Baalster wrote:Unless we can have a dynamic dialogue, I don't see the use of a system where the dialog is token based taken from a local variable. It's too limited.

Completely agreed. And even if we can do dynamic dialogue (and we can, if we really wanted to), I don't think its such a good idea. Its just plain easier to make a conversation in the conversation editor because, well, its a conversation editor!

I'm all for giving people well-documented and easy-to-follow script APIs to help them, but if we try to hide all scripting details from them for no good reason, I think it just takes a lot of power out of the system IMO.