55 replies to this topic

[Norman Barrows]

Starting work on the questgen in my project.

 

So far i've come up with the following general types of single-part quests:

 

1. attack

2. defend 

3. move

 

and for the objects of a quest (what to attack, defend or move/move to):

 

1. person/NPC/friendy unit or monster/badguy/hostile unit

2. item

3. information

4. landmark, location, building (a fixed position).

 

its seems that all types of quest are a combo of these.

 

multi-part quests are simply a series of single part quests where the reward from one part is the prerequisite for the next part, or multiple single quests must be completed for the overall reward (find the 8 holy rolls of bottom-wiping hidden across the game world).

 

have i left any out?

 

I already did the google thing both here and on the web in general, and everything seems to boil down to just these.

 

so lets play the "what category of quest is this?" game.

 

examples:

kill the dragon = destroy monster.

rescue the princess = move friendly to home. of course you have to go to the  friendly first, defeat any badguys there, and escort them back.

 

 

 

 

 

 

[Leziath]

I'm typing on my phone, so forgive the brief reply, please.
Type 4: Find. As in, locate this item or place. May involve talking to NPCs, which could, potentially, be described as a separate category, but probably not.

[Orymus3]

In the above context, fetching a mcguffin would be classified as Move("Home","McGuffin")?

[Servant of the Lord]

There's also 'achieve'/'reach'. Such as, reach level 15 or get 10 strength, or reach the top of a series of moving platforms, or reach a time-locked door that's closing slowly.

Though I guess 'achieve' could really be Move("Player", "Location") or Move("Player's Level", "Threshold")

As hinted at by the time-locked door, quests can be decorated with other requirements like time.

Another one is interacting with NPCs not for information, but to change their disposition or convince them to do or not do something. Technically, Move("NPC's emotions", "Desired state"). But if you abstract stuff too much, I guess "Kill monster" could be defined as Move("Monster's HP", "To zero"). 

Edited by Servant of the Lord, 17 February 2013 - 12:26 PM.

[Norman Barrows]

Found my notes. They weren't in the todo list, they were't in the comments, they were in the notebook where I write down bugs i find while testing or playtesting.

 

Forgot one or two actions:

1. attack/destroy 

2. defend

3. goto

4. transport

5. make/build

6. get

7. steal

8. find

 

but many of these are implied by the basic attack, defend and goto.

for example, if the quest is to find an object, that usually implies going to it, and often implies taking it to someone or some place. but the taking it somewhere is technically a second single-part quest (a goto or transport quest).

 

a transport is really a goto quest or mission - just with some cargo aboard, so to speak.

 

finding a location implies going to it usually. if the quest is to learn the location of an object, then the objective is information, not a physical location. This type of quest is common in Oblivion: go learn where the bad guys are, go tell the boss, then the boss tells you to go get them. the first part of this little 3 part quest is a quest for information. the third part is an attack quest, with a goto implied.

 

perhaps a better way to look at it is based on conditions, not "orders".

 

types of conditions checked for quest completion:

 

person/thing at location

has person/thing in inventory, i guess including has skill level / exp etc. 

person/place/thing dead/destroyed

person/place/thing alive/exists/has been made/built, inventory type objects made/built could be handled by "has in inventory"

information is known (as opposed to unknown)

time expired

any others?

 

so to assemble a quest, instead of: goto x, steal y, return to z, give to npc w.

 

it would be something like npc w has item y in inventory.

 

doesn't seem to get you much. just two different ways of expressing a quest, one in terms of orders, the other in terms of condition checks.

 

however it does allow one to express all possible types of quests as a combo of 6 condition checks. possibly useful.

[sunandshadow]

Hmm, I know we've had a thread or two here in the design forum about this topic before.  You might want to try a forum search on "quest" or "quest list".

[Norman Barrows]

Type 4: Find. As in, locate this item or place.

 

Yeah, forgot that one in the original list, then I found my notes.

 

 

 

In the above context, fetching a mcguffin would be classified as Move("Home","McGuffin")?

 

I forgot transport in the original list of actions.

 

that would be a transport quest, or a goto with has_item_in_inventory, or even more simply NPC[questor] has item in inventory (from a conditions point of view). 

 

 

 

transport seems to cover a lot of cases: kidnap and rescue quests / missions are both transport quests. transport this person to that place (possibly against their will).

 

escort might also be considered transport. you have to ensure the movement of a person from here to there, and their safe arrival. not much different from a MMO fedex for 10 rat tails. both the person and rat tails must arrive in good condition. both the person and rat tails must move (somehow) from A to B. only real difference is the person can walk, and you have to carry the rat tails. the only other difference is the implied threat of "escort" vs "transport" in an escort mission, trouble is expected, and an encounter is pretty much guaranteed. In a transport quest, no unusual trouble is expected, and the normal random wilderness and dungeon encounters are all you have to worry about.

 

the reason why i'm interested in categorizing these is because it may be possible to define a struct (or object for you OO types) that encapsulates all the variables of a single part quest. then the reward(s) from one or more single part quests can be used as the prerequisite(s) for another single part quest, allowing one to string together multi-part quests that make sense.

 

it appears that with just a few basic types of single-part quests to work with, that there are just a few basic ways that these can be combined that make sense, IE the reward from one is the prerequisite of the next. This leads to a set of just a few "templates", "themes", "scripts", "multipart quest generator types", I dont know what you'd call them.

 

"multipart quest generator types" is probably the most accurate. so the basic idea is you have these multipart questgen types which use the various types of single-part quests to generate a multipart quest with missionflow that makes sense.

 

now if it was just easy to generate storyline context to go with the mission flow, I'd be set.

 

 

 

 

There's also 'achieve'/'reach'. Such as, reach level 15 or get 10 strength, or reach the top of a series of moving platforms, or reach a time-locked door that's closing slowly.

Though I guess 'achieve' could really be Move("Player", "Location") or Move("Player's Level", "Threshold")

As hinted at by the time-locked door, quests can be decorated with other requirements like time.

Another one is interacting with NPCs not for information, but to change their disposition or convince them to do or not do something. Technically, Move("NPC's emotions", "Desired state"). But if you abstract stuff too much, I guess "Kill monster" could be defined as Move("Monster's HP", "To zero"). 

 

 

achieve stat level is sort of unique. not quite the same as has_item_in_inventory. OTOH, they are both subsets of player_has(). player_has(10 dexterity) player has(sword of slaying). which in turn is a subset of someone_has(who,what).

 

reaching the top of moving platforms seems to be more of a goto location type thing.

 

reach door in time would be goto location with time limit.

 

changing NPC disposition:  ooh! thats a good one! INFLUENCE. but influence is usually a means to an end. but at an atomic level it is a little quest unto its self. I need info from an NPC in Oblivion. But they don't like me. Bingo! Spawn new mini-quest. make this guy like you via influence, bribes, charm spells, etc. So yes influence is another valid action in games that model its effects (don't worry, mine does!). when figuring out different ways single part quests could be strung together, i found that many types of quest can be preceded by "perform a quest for someone before they will disclose the location of the main questor in a multipart quest" and even further: "perform a quest for someone before they will disclose the location of someone who knows the location of the questor". I know this sounds extreme and contrived, but in implementation its not unreasonable. this is what its like: while visiting the cave of a nearby band of friendly cavemen, doing some trading, etc, they tell you stories of a herd of huge animals said to guard a great treasure. this is the initial "quest encounter". so you decide to go after the animals and get that treasure. well, they want you to do something for them before they'll tell you where they heard about the animals (from another group of cavemen). so you do their quest, and they tell you where they heard about the animals. SO you go talk to THOSE cavemen, and they also want you to do a quest for them, before they'll tell you where the herd is. so you do that quest, then they tell you where the herd is, you go there, kill the herd, get the treasure. twists i've already played around with include another group is going after the animals as well, with both "you're ahead of them" and "they got a head start on you" versions, including the chance to encounter each other on the way to or from the herd location (and try to take the treasure if you or they got it already).  influence would play a role here. if the caveman disclosing info happens to be your best buddy, odd are he wouldn't send you on a quest. more likely he'd grab his spear and say, "Ugg! Let's go!". downside to that is that its hard enough to generate long multipart quests that make sense, without letting the player essentially skip one part cause their "bro [friendly NPC] hooked them up" so to speak.

 

but you can see what this leads to:

with a template of quest1 (do something for 1st group) to get location of quest2 (do something for second group) to get location of quest3 (herd with treasure),

you start by deciding (somehow) that you'll be using this template and that quest3 is herd with treasure (a destroy quest).

then you can randomly choose what quests 1 and 2 are INCLUDING ANOTHER ENTIRE MULTIPART QUEST! perhaps using some different template and a different final quest such as transport.  and the subquests of that multipart quest could in turn also be entire multipart quests.  

infinite recursion.

[Norman Barrows]

Hmm, I know we've had a thread or two here in the design forum about this topic before.  You might want to try a forum search on "quest" or "quest list".

 

already done. both here and web wide. that second list of 8 actions was the result.

 

to which it appears we should add "influence":

 

 

1. attack/destroy 

2. defend

3. goto

4. transport

5. make/build

6. get

7. steal

8. find

9. influence

 

 

1. person/NPC/friendy unit or monster/badguy/hostile unit

2. item

3. information

4. landmark, location, building (a fixed position).

 

 

person/thing at location

has person/thing in inventory, i guess including has skill level / exp etc. 

person/place/thing dead/destroyed

person/place/thing alive/exists/has been made/built, inventory type objects made/built could be handled by "has in inventory"

information is known (as opposed to unknown)

time expired

 

 

 

how to express it all in a database record, struct, object, etc....

it would be nice if you could simply define mission conditions and the software would generate orders based on the conditions for you.

note i'll use quest and mission interchangeably here.

but i dont see any way to do it with just conditions. they don't encapsulate all info required for mission success in all cases. player has to be told or find out which badguys to kill and where they are before a badguys_dead condition can be satisfied.

 

seems to me there ought to be a mapping , perhaps one-to-one , between quest actions and mission conditions, or a one-to-pattern mapping, for example: a given quest action always requires the same 2 or 3 types of mission conditions for success.

 

determine the patterns. that will define the vars to track. most likely vars having to do with mission orders rather than conditions. the orders will be a superset of the conditions. determine the possible patterns (templates, multipart quest gens) for combining single part quests. plug it all together. think it might work?

 

assuming something like this works ok (and it should, i've made similar things in the past), how to deal with the classic problem of generic storyline text not bringing unique context to each adventure?

[sunandshadow]

Hmm, I know we've had a thread or two here in the design forum about this topic before.  You might want to try a forum search on "quest" or "quest list".

 

already done. both here and web wide. that second list of 8 actions was the result.

Oh, you saw this one then? http://www.gamedev.net/topic/570791-mmo-quest-types/  I guess your second list does pretty much cover that.  But ok, I've got a few more:

- Gather a resource (may require a tool)

- Capture a monster

- Grow a plant

- Use X of a quest item on X monsters or locations (example there is or was a quest in WoW where you put medicine on diseased gazelles)

- Successfully execute a combo, this is kind of related to minigames like DDR and Guitar Hero where you match the pattern and timing

- Buy X (I don't really like this kind of quest, but it seems different from Find X or Build/Make X or Gather X)

Edited by sunandshadow, 17 February 2013 - 04:38 PM.

[Servant of the Lord]

What's the difference between: "6. get" and "7. steal"?

 

Isn't 'get' fighting through enemies to acquire Object?

And isn't 'steal' sneaking past enemies to acquire Object?

 

So isn't 'steal' just a specialization of 'get' that requires not being seen?

 

So it seems it would be better to add modifiers as well.

 

Quest types

• Attack
  • Subtypes:
  • Destroy

  • Hunt = Kill + Moving Objective + Multiple Objectives (optional)

  • Kidnap = Attack + Non-lethal + Get + Give... or something like that. Probably multiple steps.

  • Ambush = Kill + Moving Objective + Time limit

  • Murder = Kill + Moving Objective + Don't be caught

  • Assassinate = Kill + Moving Objective + Don't be seen

• Defend
  • Transport (Defend + Moving objective)
  • Fallback (Defend + time limit + Moving objective)
• Give
  • Deliver (Give)
  • Trade (Get + Give)
  • Threaten (Give + Information + ...?)
  • Warn (Give + Information)
• Visit / Goto
  • Visit
  • Observe (Visit + Get + Information) (see/view something occurring, possibly with the Time-limit modifyer, if it's happening in real-time)
  • Interact (touch, activate, move something)
  • Race (Visit + time limit)
• Get
  • Collect / Gather (Get + Multiple objectives)
  • Craft (Get + it doesn't actually exist yet)
  • Steal (Get + Non-lethal + Don't be seen)
  • Take (Get + dropped from an enemy (requiring kill) or pickpocketted)
  • Find (Get + unprotected but unknown location)
  • Purchase (Get + a merchant has it + No theft + Non-lethal)
• Talk / Dialog
  • Persuade / Convince / Influence
    • Deceive
    • Coerce 
    • Convert (Turn an enemy into an ally, or one political party to another affiliation)
  • Acquire information (Talk + Get + Information)
  • Give information (Talk + Give + Information)
    • Order (Talk + Give + a command)
    • Request (Talk + Ask
    • Demand (Talk + Give + a command + by emotional force)
    • Bully (Talk + Give + a command + by physical force)
    • Blackmail (Talk + Give + a command + by some kind of leverage)
  • Swap information (Talk + Trade + Information)

Objective types

• Entity
  • Enemy
  • Ally
  • Friendly
  • Neutral
  • Another player
• Item
• Information
  • Orders (Directions from a superior)
• Non-tangible power (skill level, ability, etc... Maybe part of the quest requires you to 'Get' the non-tangible ability to climb walls before proceeding further)

 

Modifiers

• Don't be caught (Can be seen, but can't be caught)
• Don't be seen (Can't be seen or caught)
• Don't kill (Non-lethal attacks are permitted)
• Don't attack (Not even non-lethals are allowed)
• Time limit
• Time window (From X to Y in the evening)
• Moving objective
• Multiple objectives

 

Then ofcourse, things are sequenced in multi-step quests to chain these together - so a 'trade sequence' is just a chain of 'Trades' - but that's a higher level up.

Edited by Servant of the Lord, 17 February 2013 - 05:24 PM.

[Norman Barrows]

- Gather a resource (may require a tool)
- Capture a monster
- Grow a plant
- Use X of a quest item on X monsters or locations (example there is or was a quest in WoW where you put medicine on diseased gazelles)
- Successfully execute a combo, this is kind of related to minigames like DDR and Guitar Hero where you match the pattern and timing
- Buy X (I don't really like this kind of quest, but it seems different from Find X or Build/Make X or Gather X)

 

variations on themes. but that's the whole idea here: there seem to be a small number of generic themes for all types of quest / missions in all types of games, apparently irrespective of genre.

 

 

 

gather resource:

get action, or someone_has(player, 50 wood) condition.

get actions can come from buying, killing and getting treasure, gathering resources, finding, pretty much any means. the fundamental goal is to place some quantity of something in someones possesion. which would lead to questgen code like: qty=dice(10), item=random_object(), for_who=npc[questor]. 

 

capture a monster:

depends on whether you have to deliver it to someone/somewhere or not.

if you do, this is a transport against their will mission (kidnap).

if you don't this is just an attack (to subdue) mission. And yes, the game supports attack to subdue, capture of subdued wild animals, taming of captured animals that are domesticable (dire wolf only at this point), killing captured animals, escape of captured animals, etc. I've tried to be thorough.    ; )

 

 

- Grow a plant:

that would probably be a make action.

 

 

 Use X of a quest item on X monsters or locations (example there is or was a quest in WoW where you put medicine on diseased gazelles):

Hmm, use of an item... that may be a new one... 

by George! looks like we got us a winner! Give that man a cee-gar!

 

 

 

 

1. attack/destroy 

2. defend

3. goto

4. transport

5. make/build

6. get

7. steal

8. find

9. influence

10. use 

 

1. person/NPC/friendy unit or monster/badguy/hostile unit

2. item

3. information

4. landmark, location, building (a fixed position).

 

1. at_location(who/what, where)

2. someone_has(who, what, how many)

3. exists(person/place/thing)

4. is_known(what, bywho)

5. time_expired(deadline)

 

i changed around the list of conditions a bit, listing them as pseudocode function calls with parameters.

someone_has() includes stats like (player, 10 dexterity).

exists() covers both the is_alive(), and is_dead_or_destroyed() cases. so i collapsed them together.

that reduces it to 5 basic types of mission conditions.

 

its hard to believe that every quest and mission in every game, book, and movie ever made consists of just a few basic elements like these. but every thread i've found online about this topic reaches the same results and comes to the same conclusion.

 

 

getting back to suggestions for the list:

 Successfully execute a combo, this is kind of related to minigames like DDR and Guitar Hero where you match the pattern and timing:

could be another new one here. everyone on my block plays sports games, NBA2K13 and Madden for the most part. I see this type of optional mission goal in those types of games frequently. Tiger woods (another popular title in the 'hood) does some of that too, as i recall. stuff about executing a trick combo or some number of trick plays, etc.

Hmm, whats a good way to list that one, so it might apply to all game types...

can't think of anything better than "execute combo/trick maneuver" at the moment.

 

and so the list grows again:

 

1. attack/destroy 

2. defend

3. goto

4. transport

5. make/build

6. get

7. steal

8. find

9. influence

10. use 

11. successfully execute

 

1. person/NPC/friendy unit or monster/badguy/hostile unit

2. item

3. information

4. landmark, location, building (a fixed position).

5. combo/trick maneuver

 

 

1. at_location(who/what, where)

2. someone_has(who, what, how many)

3. exists(person/place/thing)

4. is_known(what, bywho)

5. time_expired(deadline)

 

 

 

I can't help noticing that actions are like verbs, and the list of objects is like subjects, and parameters like bywho are like direct objects in a sentence.

 

buy x:

another version of get.

get actually is a general version of make, build, get, steal, find, gather, etc. all versions of ACQUIRE. 

if its not undesirable for the player to be able to complete a quest by any means they wish, then make, build, get, steal, find, gather, etc can all be collapsed into

acquire (by whatever means).

which would give us:

1. attack/destroy 

2. defend

3. goto

4. transport

5. acquire

6. influence

7. use 

8. successfully execute

 

and another simplification:

 

[player] goto(location) = transport(player,location)) the player transports themselves to a location. so goto is just a special case of the more general transport action, where you transport yourself.

 

now its down to:

 

1. attack/destroy 

2. defend

3. transport

4. acquire

5. influence

6. use 

7. successfully execute

 

I have a feeling that for many of these, other actions will be implied.

obviously, goto will be implied for just about everything.

 

I'm thinking that quests / missions where the game defines the goals and restrictions, but the player is otherwise free to choose the means would be superior to quests that don't allow this. Assuming the game supports this level of freedom, one wouldn't have to get into the nitty gritty special cases of steal this, grow that, gather the other, etc. you could do it all with a simple generic acquire(who, what, howmany) quest.

 

acquire(player, rat tails,10)

acquire(npc[questor], captured monster of some specific type, 1)

acquire(town center building, wood resource, 500 units)

or the final goal in the thieves guild campaign in Oblivion: acquire(The Gray Fox, Elder Scroll, 1)

 

if you needed to specify the means as well as the ends, you could always do:

AcquireEx(who, what, howmany, bywhatmeans) 

where bywhatmeans would be find, grow, gather, buy, steal, make, etc.

 

like that AquireEx?  can you tell i read too many directx docs? <g> 

[Norman Barrows]

Isn't 'get' fighting through enemies to acquire Object?
And isn't 'steal' sneaking past enemies to acquire Object?

 

you're already ahead of me, aren't you!

 

i hadn't read your post yet when i posted the AQUIRE(who, what,howmany) simplification.

 

yes, you are exactly right. and this is exactly what i want to do, determine the _fundamental_ most generic actions.

 

So it seems it would be better to add modifiers as well.

 

correct again. i hadn't gotten to that part yet. once you have your basic action (acquire, etc), and your basic parameters (who, what, howmany, etc). then come your modifiers. basically restrictions. time limit is the first, and can be applied to just about any quest. coming up with context to justify a time limit for some actions may be difficult or impossible in cases that simply don't make sense to have a time limit.

 

the second modifier would be things like bywhatmeans for the acquire() action.

 

i'd like to get to a point where you could generate a quest by picking an action from column A, parameters from column B, and zero or more modifiers from column C. throw out the cases that don't make sense, and whats left is a design for a generic questgen. possibly generic enough to use in different types of games by changing the parameters who=player or npc in an rpg, who = building or unit in a RTS, etc.

 

Wow! that list you made is Huge! I'm going to need a little time to read though them all and see whats covered already and whats not. definitely a VERY good start on the list of possible modifiers. Something tells me we'll see a number of new things on the list coming from your list, and probably a few insights and simplifications as well. A couple things like that caught my eye during a quick glance at the list. But i want to take the time to thoroughly review it to make sure i don't overlook any patterns, simplifications, etc. 

[Orymus3]

Have you studied the procedular quest determination of ProgressQuest?

[sunandshadow]

Few more:

- Avoid doing X for the duration of Y

- Consume a specific consumable

[Servant of the Lord]

'Consume a specific consumable' seems to be a 'use' sub-type

- Avoid doing X for the duration of Y

Interesting. I'm trying to think of examples of that.

A similar variation is "Keep others from doing X for the duration of Y", which is really "Defend X from others + time requirement"

Avoid doing X could easily be a modifier, "Avoid using magic in this battle", "Avoid being seen", but if it's the main focus of a quest, how would that appear?

If it's avoid letting X happen to Y, that's really "defend Y from X", if it's 'avoid letting X happen' (without a Y to happen on), I guess it's a "Stop X from happening", which is a new quest type.

 

But I can't think of 'Avoid' as a primary quest focus, and not as a modifier. Can you think of any examples?

In Final Fantasy 7 (and many games) when you are in the Golden Saucer casino, you can fight in the arena and you randomly get restraints put on you, like "No magic" - but the primary goal is "Kill the enemy".

 

Though this introduces additional quest details (that have to happen at a higher level of abstraction) differing the 'condition' modifiers of victory (Don't be seen, Don't use magic), from the Restraints (You are no longer even able to use magic). Condition = You can violate it, but you fail the quest or get a lesser victory. Restraint = You cannot violate it, that option is removed. This has to happen at a higher level of abstraction though, since logically it seems detached from the quest system itself.

[sunandshadow]

Examples of "Avoid doing X for duration of Y"

- Defend the base: keep the base from being captured or destroyed for Y minutes.

- Escort quest: keep the npc from dying before they reach the end of their gauntlet

- Gauntlet: survive in extra-hard mode for Y minutes or until the end of a physical level.

- Timed test: accomplish a goal while avoiding running out of the Y minutes on your timer.

- Enforced avoidance: consume a potion or be the target of a spell that transforms you such that you are incapable of doing one of your normal actions for Y minutes; this can't be failed unless you die or unless it's combined with another goal you have to accomplish to reverse the transformation.

- Moral/factional avoidance: you can't gain advance with faction A if you have a black mark on your record from doing something related to faction B.  You must clear your record or repudiate B to begin/resume advancing with A.

- Avoidance of the "cheap" way - you must build Z without using any of a list of the easiest/cheapest resources, and only use their more expensive substitutes.

- And as mentioned, complete a battle without using X ability, taking Y length of time, or taking Z damage

[Norman Barrows]

Have you studied the procedular quest determination of ProgressQuest?

 

 

is there a description of it or something online?

[Norman Barrows]

Servant of the Lord:

 

still digesting your list.

 

just finished looking at the get actions, about to start on talk actions.

 

under modifiers you listed:

 

don't get caught

 

isn't this already implied by any kill of someone with friends? or any non-lethal hostile action against anyone (where they're not dead and can catch you).

 

early insights gained from your list (so far):

 

 

modifiers:

don't get caught (already implied by any kill of someone with friends?)

don't be seen (covert vs overt action)

no killing (non-lethal)

methods of aquisition: make, steal, take from dead opponnet, find, gather, buy

 

 

 

other insights stumbled across in the process:

 

is_known() and someone_has() can be simplified to:

has(subject,what)  

where:

"subject" is who or what (a person or thing, IE npc or town center, etc). 

"what" can be person/monster/place/item/stat/info/prisoner

 

assumptions, things implied that don't have to be explicitly specified:

1. player's are expected to defend their party and it's possessions at all times, this includes quest items to be turned over to a questor, prisoners, escortees, etc.

2.  one must go to locations of quest events. killing Rufio implies going to Rufio's location (the inn of ill omen). This also applies to collecting quest rewards. "goto questor" is implied in "collect reward".

 

defining assumptions may go a long way towards simplifying things. anything assumed doesn't have to be explicitly specified in the single-quest data structure.

 

while doing this analysis  one needs to be careful about stringing 2 single actions together and thinking they are a separate kind of single action, when its actually a min-campaign of 2 small single quests.

 

we will need good terms for single (atomic) quest actions, and for a string or series of quest actions such as:

goto badguy (implied) + capture badguy + transport prisoner to npc

all of which can be expressed as has(npc,badguy). goto badguy is implied, capture badguy is implied, and transport badguy to npc is also implied.

 

there will be both success and failure conditions.

 

conditions that are inverses can be collapsed into "condition" and "! condition". like is_alive() and is_dead_or_destroyed() being collapsed into "if exists()" and "if ! exists()"

 

combining this with success/failure yields 4 possible checks for each type of condition:

1. success if (condition)

2. success if (! condition)

3. failure if (condition)

4. failure if (! condition)

 

needles to say, conditions can be ANDed and ORed together.

 

these combos of success/failure and condition/not condition will cover many cases that may seem at first glance to be examples of new actions or conditions or quest types.

 

I've made a few quest and mission generators before. condition records usually take the form:

success/failure: whether its a condition for success or failure.

condition_type: including details for that condition like how many rat tails, possibly stored in generic data fields: condition_data[0]=rats, condition_data[1]=10.

and_with_next_condition:  if true, AND this condition with the next one to make a compound condition: has(vaccine) AND has(treaty) AND has(Lieutenant Yar).

 

one might need a NOT field in there too, but usually a  "success if (! condition)" = failure if (condition), and vica vesra.

 

The most insanely huge generator i ever made was for a Star Trek flight simulator. A politics engine (in a game with five factions) drove about a dozen types of campaign generators, which in turn drove about 2 dozen types of mission generators. Each mission generator could generate anywhere from a couple dozen to over 40,000 different kinds of missions before you even got into number appearing or initial placement. as politics between factions changed you changed from peacetime to wartime campaigns, for example, with appropriate missions against the appropriate faction. All mission flow within and between campaigns made sense.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Norman Barrows]

Servant of the Lord:

 

Looking at these talk actions...

 

deceive looks to be a give/deliver/transport info action, where the info is false.

 

hmm... transport information, how many quest actions fit that description?  may be more opportunity for simplification.

 

coerce: implies some means of coercion. this would probably be some type of "do harm until they give you info". a subset of get info or has(player,info). if you're free to get the info by any means (bribery vs coercion for example), its just a "get info" quest, if coercion is required by the questor, its would most likely be a get_info quest with a by_what_means modifier. its might be easier to handle with the conversation AI system than quest engine. IE no npc gives info to hostiles until x amount of harm is done to them first. so a has(player,info) quest where has(badguy,info) is the initial condition, would automatically imply coercion of some sort, such as the "attack to subdue" feature in the game i'm working on.

 

Oblivion has a coercion quest in the fighter's guild campaign. you kidnap a badguy, then you're supposed to damage him some and he talks some, then damage him some more and he spills his guts.  last time i played it, i started by bribing the guy to max disposition. never had to throw a single punch at him. got done bribing, and it immediately went to "looks like he's ready to talk now", and then to "looks like he's had enough and will sing like a canary now". sure he's had enough! enough of my gold! <g>.

 

convert is an influence type action. influence should probably be listed as: influence/convert

 

give info would be a transport info action, I'd think.

order is a special case of give info. info: what to do (orders). from: superior. to: subordinate.

demand: seems to simply be a step along the way to competing a  quest. you don't get mission completion by demanding the enemy remove its troops from your border, you get it when they comply, unless your the ambassador. in that case, you're playing messenger: transport info (demand) to badguy.

bully, similar case. if you're the "muscle", then this would probably be some sort of influence action with harm implied. You're using harm to influence someone's actions. Punch them in the nose and demand their lunch money or you'll do it again. of course another way to look at it is with the more generic has(bully,lunch money).

 

I really like that Has() condition! it implies and encapsulates so much!

 

it occurred to me that some conditions will automatically imply others: has(town center,500 wood) implies exists(town center). obviously, exists() will be implied in almost all cases.

 

blackmail is giving a threat to get an action from someone (such as they give you something, etc). if you don't get the action, you follow through on the threat.

that would probably be classified based on the action your trying to get. if you're blackmailing for money it would be acquire money, with a by_what_means modifier of blackmail. blackmail and coercion are tricky, you have to have something you can hold over them.

 

swap info is a two part quest: get info + give info.

 

moving objective modifier:

probably can be assumed. objectives that can move will move. you'll just have to goto(them).  i'm kind of thinking that all travel required can be implied and assumed and doesn't need to be specified. except perhaps for the most basic case of at(player,location) IE a simple goto quest. 

[Norman Barrows]

I guess it's a "Stop X from happening", which is a new quest type.

prevent(condition) = failure if (condition).

looks like (condition) will determine the quest type, and a "prevent" quest is simply one with "failure if (condition)". note that such a quest would also require a success condition such as is_time(deadline), or perhaps whatever the counter-pose to "if (condition)" would be. it wouldn't be (! condition), as that's the starting state of the quest.

Edited by Norman Barrows, 18 February 2013 - 10:33 PM.