Procedural generation based on data and not presence?
Procedural generation based on data and not presence?
Hey,
I've been reading about your package for the past couple of days and I am even thinking of getting love/hate and while I like what I see I have an important requirement which I am not sure whether or not this package will be able to satisfy. Basically I want my quests to be generated based on data and relationship(i.e. low on food, do a food quest, npc starts to hate another npc so you have a couple of quests centered on that, etc, I think you get the point). Do note that most of the npcs or data will be generated and changed procedurally. Would I be able to use the package in my intended use case? I realize that currently the quests are generated by the entities in the domain but mine is a bit more abstract (or I don't realize how to use your package in a more abstract way), since there are no i.e. npcs present on the map, they are just game objects. Do you have any tips for how to achieve this?
I have some other smaller questions:
How easy would it be to incorporate love/hate in this kind of set up to help with relationship and quest generation?
I've read that you can easily extend the package to include a failed condition... how easy would it be really( could I just send a message with a failed part in it)? How about starting other quests after finishing with like 25% percent chance of starting? How about quests with multiple branches?(I've read that it's quite hard to implement this one so I think I will figure something else)
And lastly I didn't want to start a whole new topic for this but can you ignore the love/hate ped model(don't really want people doing things based on emotion at least not rn) and just use their stats and affinity for relationships?
I've been reading about your package for the past couple of days and I am even thinking of getting love/hate and while I like what I see I have an important requirement which I am not sure whether or not this package will be able to satisfy. Basically I want my quests to be generated based on data and relationship(i.e. low on food, do a food quest, npc starts to hate another npc so you have a couple of quests centered on that, etc, I think you get the point). Do note that most of the npcs or data will be generated and changed procedurally. Would I be able to use the package in my intended use case? I realize that currently the quests are generated by the entities in the domain but mine is a bit more abstract (or I don't realize how to use your package in a more abstract way), since there are no i.e. npcs present on the map, they are just game objects. Do you have any tips for how to achieve this?
I have some other smaller questions:
How easy would it be to incorporate love/hate in this kind of set up to help with relationship and quest generation?
I've read that you can easily extend the package to include a failed condition... how easy would it be really( could I just send a message with a failed part in it)? How about starting other quests after finishing with like 25% percent chance of starting? How about quests with multiple branches?(I've read that it's quite hard to implement this one so I think I will figure something else)
And lastly I didn't want to start a whole new topic for this but can you ignore the love/hate ped model(don't really want people doing things based on emotion at least not rn) and just use their stats and affinity for relationships?
Re: Procedural generation based on data and not presence?
Hi,
Thanks for your interest in Quest Machine and Love/Hate! You can do everything you asked, except the procedural quest generator currently doesn't generate failure conditions. You get a quest (e.g., Kill 3 Rats) and you either do it or you don't. Failure conditions in hand-written quests are no problem.
A typical Quest Machine game where data are represented by objects in the scene works the same way. The NPC generates a world model, which is a list of things it knows about. If the world model contains a sandwich and the NPC is hungry, the sandwich will have a high urgency value to the NPC. This increases the chance that the NPC will generate a "fetch me a sandwich" quest.
Urgency functions can be more abstract, too. Say the NPC is looking for love. If the world model contains a potential partner, it might return a high urgency, and the NPC might generate a "tell X I like him" quest.
In fact, this is exactly what The Lonely Gorilla does. The protagonist has drives (hunger, companionship, etc.). It uses Quest Machine to identify objects (food, mates, rivals) that help satisfy those drives. If I recall correctly it manages relationships using Love/Hate.
For the 25% thing, you'd just add a custom Autostart Condition or Offer Condition that rolls the dice and returns true only 25% of the time.
Thanks for your interest in Quest Machine and Love/Hate! You can do everything you asked, except the procedural quest generator currently doesn't generate failure conditions. You get a quest (e.g., Kill 3 Rats) and you either do it or you don't. Failure conditions in hand-written quests are no problem.
Quest Machine borrows the "smart object" concept from The Sims. When a sim needs to decide what to do, it asks nearby objects what benefit they can provide given the sim's current state. Then it chooses the object that provides the greatest benefit. For example, say the sim is hungry but well rested. A sandwich will provide high benefit, but a bed will provide low, so the sim will choose the sandwich.
A typical Quest Machine game where data are represented by objects in the scene works the same way. The NPC generates a world model, which is a list of things it knows about. If the world model contains a sandwich and the NPC is hungry, the sandwich will have a high urgency value to the NPC. This increases the chance that the NPC will generate a "fetch me a sandwich" quest.
Urgency functions can be more abstract, too. Say the NPC is looking for love. If the world model contains a potential partner, it might return a high urgency, and the NPC might generate a "tell X I like him" quest.
In fact, this is exactly what The Lonely Gorilla does. The protagonist has drives (hunger, companionship, etc.). It uses Quest Machine to identify objects (food, mates, rivals) that help satisfy those drives. If I recall correctly it manages relationships using Love/Hate.
Finally getting to your question (sorry for the long background info above): By default, NPCs generate a world model by tracking GameObjects that enter specified collider areas. However, you can also provide your own C# method to add whatever facts you want into the world model, even if they don't exist in the scene. Assign it to the NPC's QuestGeneratorEntity.updateWorldModel delegate. The method receives a WorldModel object. You can add or remove Facts from it. Example:darkmajki wrote: ↑Sat Apr 13, 2019 7:51 amDo note that most of the npcs or data will be generated and changed procedurally. Would I be able to use the package in my intended use case? I realize that currently the quests are generated by the entities in the domain but mine is a bit more abstract (or I don't realize how to use your package in a more abstract way), since there are no i.e. npcs present on the map, they are just game objects. Do you have any tips for how to achieve this?
Code: Select all
GetComponent<QuestGeneratorEntity>().updateWorldModel = AddExtraFacts;
...
void AddExtraFacts(WorldModel worldModel)
{
// This NPC always knows there's a banana in the fridge:
worldModel.AddFact(fridge, banana, 1);
}
Pretty easy. Quest Machine comes with a drop-in integration package that replaces its rudimentary faction system with Love/Hate's more sophisticated relationship model.
Hand-written quests with multiple branches are no problem. The procedural generator can generate quests with multiple steps, but not separate branches. That said, you can always design those steps so there are multiple ways to complete them. You could remove rats from the basement by killing them or leading them away, as long as it satisfies the generated requirement (e.g., no rats in basement).darkmajki wrote: ↑Sat Apr 13, 2019 7:51 amI've read that you can easily extend the package to include a failed condition... how easy would it be really( could I just send a message with a failed part in it)? How about starting other quests after finishing with like 25% percent chance of starting? How about quests with multiple branches?(I've read that it's quite hard to implement this one so I think I will figure something else)
For the 25% thing, you'd just add a custom Autostart Condition or Offer Condition that rolls the dice and returns true only 25% of the time.
Sure. PAD's optional.
Re: Procedural generation based on data and not presence?
Hey,
Thank you for your response.
No problem about the long background info, I did know Sims used utility theory(and this smart objects seems to be part of it), it's always good to know the background ideas behind implementations.
It's great that your packages fit my use cases(I was thinking maybe that wasn't the intented use case) but now I will definitely buy them in the coming days. I would definitely come up again a couple of times with a follow up questions, since I didn't saw in the manual any real examples about adding facts and the general complexity of QuestMachine means I would need a bit of time to digest all of this and some follow up questions
Thank you for your response.
No problem about the long background info, I did know Sims used utility theory(and this smart objects seems to be part of it), it's always good to know the background ideas behind implementations.
It's great that your packages fit my use cases(I was thinking maybe that wasn't the intented use case) but now I will definitely buy them in the coming days. I would definitely come up again a couple of times with a follow up questions, since I didn't saw in the manual any real examples about adding facts and the general complexity of QuestMachine means I would need a bit of time to digest all of this and some follow up questions
Re: Procedural generation based on data and not presence?
Please feel free to work with the evaluation version for a while before buying to make sure it fits your needs. It has all the features of the paid version except it has a watermark and no source code.
Re: Procedural generation based on data and not presence?
Hey I didn't had as much time as I had hoped to try it out and I just started today and as I said I will be coming back with more questions . I installed everything and I am already hitting a wall... How can Quest machine generator get the factions from a faction database? And how would I set a entity in a quest machine to be part of that faction? Also is it possible the drive values to be from the love/hate traits? The quest machine love/hate integration package didn't seem to answer any of my questions.
Re: Procedural generation based on data and not presence?
Hi,
Let's say you're writing a fantasy game with elves and orcs in a forest. Your data is set up like this:
When an NPC considers Orcs, the urgency to generate a quest will be based on this urgency function, which is defined as the amount of negative Love/Hate affinity. Since the NPC's Elf faction has -100 affinity to the Orc faction, it has +100 urgency to generate a quest about Orcs. Unless it finds an entity type with higher urgency, it will generate a quest about Orcs.
The integration manual doesn't make it clear enough that Quest Machine entity type names must match Love/Hate faction names. It's currently just a single sentence at the bottom of page 5, and it's poorly worded at that. I'll make this clearer in the next update.
Let's say you're writing a fantasy game with elves and orcs in a forest. Your data is set up like this:
- Two Love/Hate factions: Elf and Orc. Elves hate orcs, so they have -100 affinity to orcs.
- Two Quest Machine entity types: Elf and Orc. (Names match Love/Hate factions.)
- Your scene has a Faction Manager GameObject (for Love/Hate) and a Quest Machine GameObject.
- An Elf NPC has a Quest Generator Entity component that watches the forest domain. There are orcs in the forest. They have Quest Entity components that are assigned the Orc quest entity type.
When an NPC considers Orcs, the urgency to generate a quest will be based on this urgency function, which is defined as the amount of negative Love/Hate affinity. Since the NPC's Elf faction has -100 affinity to the Orc faction, it has +100 urgency to generate a quest about Orcs. Unless it finds an entity type with higher urgency, it will generate a quest about Orcs.
That's a good idea. I'll try to get that into an update soon.
Re: Procedural generation based on data and not presence?
Hey,
I've been tinkering with the package for the past couple of days and so far so good, it's generally a great package and I would be getting it in the next couple of months as I plan on getting the game on early access and I've been making progress(although I can't say that I've tested everything I wanted to know since the quests are partially based on a much bigger system and I still haven't finished implementing everything there). Anyways, I've got a couple of questions which might be the last I ask(or at the very least last for the time being).
Specifically I can't understand how to go about some of the issues from my first post:
1. There isn't a way to fail a quest, but how would I go about i.e. there is a battle nearby but that battle is only there as a quest for 5 turns. After that the quest shouldn't be available? How would I go about this? Just remove the quest from the quest log and that's it?
2. You said it's possible to have a quests that has a chance of start of a lets say 25%, but you mentioned autostart conditions and as I understand that's not available in procedural quests. Is there a way to do it with a procedural quest?
3. How would I create the branching nodes and multiple nodes procedural quests? I understand how to create actions and all that but how do I chain them together? And how do I add multiple actions for the same entity( for the branching quests) in the same quest?
Hopefully I am not asking too many questions .
I've been tinkering with the package for the past couple of days and so far so good, it's generally a great package and I would be getting it in the next couple of months as I plan on getting the game on early access and I've been making progress(although I can't say that I've tested everything I wanted to know since the quests are partially based on a much bigger system and I still haven't finished implementing everything there). Anyways, I've got a couple of questions which might be the last I ask(or at the very least last for the time being).
Specifically I can't understand how to go about some of the issues from my first post:
1. There isn't a way to fail a quest, but how would I go about i.e. there is a battle nearby but that battle is only there as a quest for 5 turns. After that the quest shouldn't be available? How would I go about this? Just remove the quest from the quest log and that's it?
2. You said it's possible to have a quests that has a chance of start of a lets say 25%, but you mentioned autostart conditions and as I understand that's not available in procedural quests. Is there a way to do it with a procedural quest?
3. How would I create the branching nodes and multiple nodes procedural quests? I understand how to create actions and all that but how do I chain them together? And how do I add multiple actions for the same entity( for the branching quests) in the same quest?
Hopefully I am not asking too many questions .
Re: Procedural generation based on data and not presence?
Yes. You can call QuestJournal.DeleteQuest(), passing either a quest ID or a quest object itself. (Or QuestGiver if you're removing it from an NPC.) Or you can call QuestJournal.AbandonQuest() to set it to the abandoned state if you prefer.darkmajki wrote: ↑Thu Apr 25, 2019 6:38 am1. There isn't a way to fail a quest, but how would I go about i.e. there is a battle nearby but that battle is only there as a quest for 5 turns. After that the quest shouldn't be available? How would I go about this? Just remove the quest from the quest log and that's it?
You can assign a delegate method to the NPC's QuestGeneratorEntity.generatedQuest event. The method will receive the generated quest as a parameter. You could add a condition to the quest's Quest.autostartConditionSet or offerConditionSet. Assuming you've written a custom condition called PercentChanceCondition, it would be something like:
Code: Select all
GetComponent<QuestGeneratorEntity>().generatedQuest = OnGeneratedQuest;
void OnGeneratedQuest(Quest quest)
{
var condition = ScriptableObject.CreateInstance<PercentChanceCondition>();
condition.percent = 0.25f;
quest.autostartConditionSet.conditionList.Add(condition);
}
The procedural quest generator generates linear quests (do this, then do that). To make branching quests (do this or that, then do this and that), you'll need to write some code. Use the QuestBuilder class. Quest Machine includes an example script named QuestBuilderExample.cs.darkmajki wrote: ↑Thu Apr 25, 2019 6:38 am3. How would I create the branching nodes and multiple nodes procedural quests? I understand how to create actions and all that but how do I chain them together? And how do I add multiple actions for the same entity( for the branching quests) in the same quest?
Re: Procedural generation based on data and not presence?
Thank you for your support. You are very helpful. 1. and 2. are perfectly clear. About the 3. I looked at the QuestBuilderExample and the code is clear and understandable enough, but one thing I am wondering is how would I be able to add a generated quest into a questbuilder? Call generatequest and in the delegate adding the quest to a questbuilder doesn't seem like a good way to me and I can't think of a better one.
Re: Procedural generation based on data and not presence?
I'll add that as an option in the next version. You'll be able to create a new QuestBuilder but provide an existing quest. I'm trying to get the next version out early next week. I'm running a local Ludum Dare jam site this weekend, so it may end up being early-to-mid next week.