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

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.