Tips on writing quest machine integration for Behavior Designer for AI Questers.

[LethDavidson]

Howdy!

So my employer is making a big open game where the AI goes and completes tasks and they want to structure it around Quest Machine's dynamic questing system, and use Behavior Designer. (think STALKER and how it's characters have goals and personal objective, if you've ever played that.)
Now i sorta realized a bit late that there isn't an integration package, which i guess i just assumed there was one given that there existed one for L/H and DS but that's my bad.

Anyway i'm cool with writing the integration myself, but before i dig into it i'm curious if there's any recommendations you'd make for how to structure/do it?

The AI is going to need to:
1. Get Tasks From Quest Givers and store relevent info from them in the blackboard,
2. communicate with eachother about what quests they're on so they don't double up (or choose to race eachtoher to a thing).
3. general be able to quickly communicate with the quest machine thing so that it understands Zones,
4. perhaps even some internal system which lets them make choices based on how much time is left in a quest.
5. More or less use it as an adhoc Objective System for moving around a map and completing tasks an AI director gives it
6. other stuff i haven't thought of i'm sure as i haven't done this before and i'm not the most experienced coder.

I think i know how it'd DO most of that, just writing alot of custom tasks which pull that info and slot it into the right places automatically, and some generic Sharing Info quests that just happen to share quest info. But if there's any progress/WIP version of the integration on the backburner, a few tips/notes would be lovely.

[Tony Li]

Hi!

You're going to want to bookmark this: Quest Machine API

The AI is going to need to:
1. Get Tasks From Quest Givers and store relevent info from them in the blackboard,

API: QuestGiver (also related: Quest, QuestJournal, QuestMachine, )

The static QuestMachine class is useful for getting a lot of general information.

Once you have a reference to a QuestGiver, you can check its questList, which is a List<Quest> of quest instances. When a quest giver gives a quest to a player, the player gets its own instance of the quest. So if you want to get the player's current progress in a quest, make sure to check the player's instance. Get it from QuestMachine.GetQuestJournal().questList.

I'll include misc. notes below:

2. communicate with eachother about what quests they're on so they don't double up (or choose to race eachtoher to a thing).

For procedurally-generated quests, you can check Quest.goalEntityTypeName. This is the EntityType that the quest is about (e.g., Rabbit in a "Kill 3 Rabbits" quest).

The script that manages a quest giver's procedural quest generation is called QuestGeneratorEntity. If another quest giver already has a quest about rabbits, you can hook into QuestGeneratorEntity.updateWorldModel to remove the Fact about rabbits from the world model so the QuestGeneratorEntity doesn't generate a quest about it. Then again, maybe you want to generate another quest rabbits. A farmer could ask the player to kill the rabbits, but an animal-loving druid would ask the player to save or relocate the rabbits.

3. general be able to quickly communicate with the quest machine thing so that it understands Zones,

What kind of Zones? Quest Machine's Quest Domains? Or something else?

4. perhaps even some internal system which lets them make choices based on how much time is left in a quest.

Certainly possible. It would depend on how you're counting time. If the quest has a timer quest condition, it will record the time left in a counter. You can check that counter.

5. More or less use it as an adhoc Objective System for moving around a map and completing tasks an AI director gives it

Use the QuestBuilder class to create quests in code. (There's an example in the manual.) Your AI director can do this to create objectives at runtime.

[LethDavidson]

Oh wow i appreciate the detailed info, i'll def start messing around with all that. I'm currently just doing a basic adaption of the demo scene to make it work with a btree before i get into building too much custom stuff.

As for Zones, that's mostly rambling about how I'd want to sort/hold data. The idea is that there map would be split up into large and small zones where questing stuff can happen it/general tactical data can be read from. I was referring to the quest machine zone system which came up in one of the tutorials, which lets it check a trigger-area to see it's conditions and decide what it wants to do there. I don't THINK i'd need a custom solution at that point as my own idea of zones could prob piggyback off of that, or use the quest machine zone system as one part of an area's data.

But yeah, a general "I should go fish in a nearby Fishing Zone", or "I've been told to get to City Zone A and defeat the General there, which means i must pass through Grass Zone B, And Ice Zone C to get there." SO just amounting to checking what zones they're in/going to move through and making decisions based off that. I mean that sounds simple, just pulling from some list somewhere and doing codecheckss based on values i may additionally associate with them (like fishing zones may also have a Danger script on them as well which may influence how my AI decides if they should take a quest/how danerous doing it may be)

blah blah anyway yeah i appreciate those links and i'll def get to adapting them.

One last question; do you forsee any potential problem with using Quest Machine as a kind of objective System for an AI? Such as... the town's low on food, so the town sends a signal out to generate a quest to go get more food, and an AI gets/is assigned that task, forms a team, then heads to where they know they can complete that task. And in general the town sends out alot of quests as needed in order to get things done; defeat this enemy, bring back this resource, someone heal this specific person, ect.

QM Sounds like a good way to do this kind of monitoring and reacting in a way that an AI will be able to quickly grab onto and understand, but i'm unaware of any potential downsides that using QM to conceptualize all of these tasks could bring, especially on a smaller scale such as an ai squad leader telling it's team to go to Spot and hold it, or something.

[Tony Li]

An objective system is a good use for Quest Machine's procedural quest generation. For the town example, you could make the town storehouse an entity whose urgency function has a high value when food is low. Animal entities outside the town could have actions that produce meat entities when hunted. And meat entities could have an action to replenish the storehouse. So Quest Machine would generate a quest to replenish the storehouse, and it would choose the actions [hunt animal] --> [bring to storehouse] to complete the quest.