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

failure if has(enemy,base) or ! exists(base). success if time_is(deadline).

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

transport(npc,location)

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

success if at(player,end of level) or is_time(deadline). "extra hard mode" might be a modifier, or simply reflected by the difficulty level of opponents encountered.

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

success if (condition), failure if is_time(deadline).

- 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.

consume potion is a use action. not quite sure how "be target of spell or effect" would be classified. might be a new action: be guinea pig.

- 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.

what you have to do to fix things would be the action here, i believe. I accidentally kill a mage's guild member while on a mission for the assasin's guild, thereby getting suspended from the mage's guild. now i have to find 20 dragon's tongue and 20 redwort flowers to be readmitted. a straight up has(player,20 redwort and 20 dragon's tongue) quest.

while looking over the types of quests, the following came to mind:

who = subject

what = action

- 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.

make action with modifiers. has(player,Z). modifiers: can't use A, can't use B, can't use C.

success: has(player,z) + failure: use(player,a) + failure: use(player,b) + failure: use(player,c)

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

success: ! exist(badguys) + failure: use(player,X) + failure: time_is(deadline) + failure: has(player, Z amount of damage)

this stuff is starting to almost look like a little quest programming language!

a wargame i have in alpha right now has a built-in mission editor, including a conditions editor. filling in the conditions for a mission in it is sort of like writing a little program.

there are statements: success if ...

and syntax: success|failure condition+mods [AND]

when its time to check conditions, the code applies the checks listed, sort of like an emulator running a script.

just occurred to me that a time window is a compound condition. failure if before time t1 + failure if after time t2, IE:

failure: ! time_is(t1) AND "primary condition is true" + failure: time_is(t2)

"primary condition is true" could be most anything: has(player,item to be stolen), etc.

so a time window can be handled by two time_is() condition checks, one ANDed with the primary mission conditions (such as fedex 10 rat tails).

need to keep an eye out for compound stuff that appears to be single stuff at first glance.

ok, been digesting and sifting over this stuff now for over a day.

here's what i've done so far:

the state_is(subject,state) condition check:

while assigning checks to actions,it appeared that a new check was required for "execute combo" actions:

state_is(player,kicking) + state_is(player,spinning) + state_is(player,jumping) = did combo

or for a flight simulator:

state_is(last_maneuver,1/2 roll) + state_is(maneuver_before_last,1/2 loop) = Immelmann turn.

this new condition check "state_is(subject,state)" turned out to encompass all other checks:

I would think caught would be being seen while doing an action in a list of "suspicious" or "illegal" actions. Prerequisites might include faction membership or rank, race, class...? Are spawned resources items? They probably shouldn't be locations. How about plants, pets, mounts...?

How about a quest to play a minigame and pass a minimum number or levels or target score? Or solve a puzzle?

What if you're in the middle of a quest to deliver an object to an NPC and that NPC gets killed?

QUEST ACTIONS:
...
8. be guinea pig.
...

consume potion is a 'use' action. not quite sure how "be target of spell or effect" would be classified. might be a new action: be guinea pig.

I think this one needs to be clarified a bit more.

"prevent(condition)" seemd to be the NOT case of other types of quests, so I removed it from the list of actions.
prevent(capture/destruction of target)=defend(target).
prevent(arrival,object,location)=acquire/destroy/convert(object) and/or destroy/acquire(capture)/convert messenger

Good insight!

1. don't get caught. need definition of "caught". don't get caught might be assumed.
2. don't be seen (covert vs overt action)

what's the definition of "don't get caught" and is it already implied in any quest that might use it?

The difference between 'don't be caught', is when assassinating someone or stealing something or ambushing a group, and it is permitted to be seen but not caught. Being seen immediately afterward is assumed, but victory is only when you successfully escape afterward, so the quest doesn't count as 'completed' until a successful escape.

But on thinking about it, it really is just two steps:
A) "Get/steal item" or "Kill person"
B) "Goto location" (implicit: Don't get killed)

So 'don't get caught' could be removed.

However, instead of 'Goto escape_point' to escape, a more flexible option would be 'leave ambush_point'. Or, 'Goto NOT ambush_point'. This way the player won't mess up the quest flow if they exited through some location other than what the designer expected.

Actually, the more the quest goals specify the desired outcome, and not the specific means of outcome, the more it seems the quest system would permit emergent solutions to quests.

For example, though 'kill' is a descriptive word to use, it really shouldn't be "<player> <kills> <target>", because the player might decide to set a trap and the trap might kill the target, or the player might agro a bear and lead the bear to the target and the bear gets the kill. For greater flexibility, "<target> <is> <dead>" is a more concrete quest goal - it's either true or false. Whereas "<player> <kills> <target>" can have three states: 'Target is still alive', 'player killed target', or the harder to detect 'something other than the player killed the target and now the quest is unable to be completed and unable to be failed'.

The more the quest goals query state, I think the more durable they are - but I'm not entirely sure.

If you go for a state-based system, then your 'actions' and 'modifyers' become merged together:
"<player> <steal> <item> <without killing anyone>"
"(<player> HAS <item>) AND (<player> HAS_NOT <killed_anyone_in_area>)"

This also resolves your guinea-pig action (which isn't really an 'action' and was hard to fit in).
It really is "<player> HAS <effect_applied>"

Quest actions and modifyers can be unified:
QUEST ACTIONS | States instead of Actions
1. attack/destroy => "target IS dead"
2. defend => "target IS alive" (when the quest status is queried)
3. transport => "player HAS item AND player AT location"
4. acquire => "player HAS item"
5. influence/convert => "target IS angry", "target IS afraid" (threaten success), "target IS friendly" (persuasion success), "target IS member_of_gamedev" (conversion success)
6. use/interact with => "object IS activated", "item IS used"
7. successfully execute (do something [combo/trick move]) => "player HAS executed_combo", "player HAS accomplished_impressive_feat_num27"
8. be guinea pig. => "player HAS effect"
9. unique actions germane to the specific title (in case we forgot anything) (as shown in the 'successfully execute' example - new things specific to certain titles fit into this system without new 'actions' needing to be added - merely new states, which are easier to add)

(<target> <operator> <state>) chain (<target> <operator> <state>)

operators = IS, IS_NOT, HAS,HAS_NOT, HAS_MORE_THAN, HAS_LESS_THAN, HAS_BETWEEN
chains = AND OR XOR

"player HAS_MORE_THAN(15) rose_petals"
"player HAS_BETWEEN(10,20) rose_petals"

MODIFIERS | States instead of Modifiers
1. don't get caught =>
2. don't be seen => "<goal> AND player IS_NOT seen"
3. no killing (non-lethal only) => "<goal> AND player IS_NOT seen"
4. methods of aquisition => "<goal> AND player HAS item AND player HAS_NOT stolen"
5. Don't attack => "<goal> AND player HAS_NOT attacked"
6. time limit/window => "<goal> AND player HAS_MORE_THAN(0) time_left" / "<goal> AND player IS_NOT out_of_time"
7. using special item / power etc. usually the special item / power is one time use only. "<goal> AND player HAS_NOT item"

I would think caught would be being seen while doing an action in a list of "suspicious" or "illegal" actions.

Yeah, since i didn't hear back from anyone on this question, I forged ahead with my own analysis. I came to the same conclusion:

"don't get caught" is a modifier for any quest action that "breaks the law".

Are spawned resources items? They probably shouldn't be locations. How about plants, pets, mounts...?

when i use Caveman as a test case during analysis, i treat resources as objects for acquire() actions, and places where resources are available as locations for atk/def() type actions.

How about a quest to play a minigame and pass a minimum number or levels or target score? Or solve a puzzle?

I'd call that one a use/interact with special item quest, where the mini-game or puzzle is the special item.

What if you're in the middle of a quest to deliver an object to an NPC and that NPC gets killed?

yes. for each type of quest, there will be certain circumstances that will prevent completion. these will probably be best handled as automatic failure conditions that will apply to all appropriate types of quests. example: failure if state_is(questor,dead) for all quests that have a questor who you must return to to get the reward. many games are poor at this, or don't trap all cases. some like Oblivion cheat, and make the questors indestructible - hence the dead questor problem goes away.

However, instead of 'Goto escape_point' to escape, a more flexible option would be 'leave ambush_point'. Or, 'Goto NOT ambush_point'. This way the player won't mess up the quest flow if they exited through some location other than what the designer expected.

the way to do it will be to define conditions in terms of final outcome, and required modifiers alone, and make no other assumptions about means used.

so a destroy (murder) quest with a "do not get caught" modifier might be expressed as:

success: target dead + player @ questor location. failure: player arrested. failure: questor dead.

this avoids the whole ambush thing, worrying only about the final results that matter, not how they come about. This avoids having to think of every possible case, and gives the player maximum leeway in completing quests. as long as the game supports getting arrested, no further work is required.

Actually, the more the quest goals specify the desired outcome, and not the specific means of outcome, the more it seems the quest system would permit emergent solutions to quests.

PRECISELY!

The more the quest goals query state, I think the more durable they are - but I'm not entirely sure.

I suspect that all quest conditions should test final states, not methods used. remember, "using specific method" is a modifier that creates its own condition checks in addition to those for the regular version of the quest with no modifiers.

kill rufio = state_is(rufio,dead)

kill rufio w/ blade of woe = state_is(player's current weapon,blade of woe) + state_is(player's current target,rufio) + state_is(player,hit target and did damage) + state_is(rufio,dead).

This also resolves your guinea-pig action (which isn't really an 'action' and was hard to fit in).
It really is "(player) HAS (effect applied)"

another insight!

state_is(player, effect applied) is the check. "be guinea pig" is the orders.

Quest actions and modifyers can be unified:

yes, each quest type and modifier will have specific types of checks associated with it, and add the same type of checks each time.

but i found that listing the possible types of quests for a given title was much easier based on actions and modifiers, than by considering all the possible checks that might make a logical non-lame quest.

ok, here's what i've done since my post of feb 21st:

1. figured out that "without getting caught" is a modifier for quests that "break the law".

2. listed the basic variables required to track a singe quest.

3. determined that orders, checks, and prerequisites are derived from action, object, and modifiers, and do not need to be specified.

4. defined some terminology: a series of quests is a campaign. a campaign is made up of stages. a stage is made up of one or more quests.

5. determined the basic types of stages: single quest (linear), split/merge (2 paths that meet again), loop (repeat on failure kinda stuff), split (branching story line), and multiple-simultaneous (get the 8 things in any order). did i miss any?

6. determined templates for each type of stage. example:

split/merge: success quest A -> next stage. failure quest A -> compete 1 or more stages to continue to next stage. this provides mission flow that splits then merges again.

my biggest concern, is that except for campaigns like: "get A to open B to kill C", everything seems of be of the form: do quest A to get location of questor B. which can only be strung out so many times before appearing contrived. this leads to campaigns of the form: do X to get location of a guy, who knows a guy, who knows a guy, who knows a guy, who knows where the dragon is. doing quests for each guy along the way, til you finally learn where the dragon is, kill it, and get the treasure.

This is where you then learn to incorporate creativity to mix it up so that it does not seem to be so repetitive. For example:

You enter a tavern and listen to a man who tells a story of an adventure about some bloke who inadvertently picked up an orb of vision and proceeded to see a sleeping dragon on his mound of treasure, tracking this guy down you learn that he sold it to a passing merchant, who subsequently had sold it to a noble who had then dispatched the orb along with some of his knights to slay the fell beast and claim the treasure, but no word has been heard of them in quite some time...[queue dramatic music ].

edit: The point being is that whilst you have atomised your quests down to a set of basics - the story variations upon those basics are only limited by your imagination.

edit: 36 Dramatic situations