• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Norman Barrows

Types of quests

55 posts in this topic

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

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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

1

Share this post


Link to post
Share on other sites

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")happy.png

 

 

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.

1

Share this post


Link to post
Share on other sites

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?

1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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. 

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

 

0

Share this post


Link to post
Share on other sites

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. 

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

- 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

when = timeframe
where = location
why = reason
how = method
 
the example you gave for moral/factional avoidance, and my counter example point out the fact that WHY really doesn't factor into the type of quest. its story line context to bring logic to the mission flow, IE to make WHY you're doing a quest make sense. but the motivation for undertaking a quest is a separate issue from the types of quests that can be undertaken, and a much more protracted can of worms. Once the types of quests are identified along with subjects, modifiers, conditions, etc, and the types of multi-part quest generators are identified, the next step is to figure out how to generate a storyline or mission orders for the generated quest. This is probably where the "why" would come into play. but from the standpoint of generating the quest itself, I would think the generator couldn't care less why the player has to do the quest, it just turns a crank and says "here you go, here's your quest!" it would probably require a higher level system such as the politics engine driving the campaign generators in my Star Trek flight simulator to provide the why. 
 

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

Edited by Norman Barrows
1

Share this post


Link to post
Share on other sites

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

 

here's what i've done so far:

 

 

1. collated the lists
 
2. simplified/combined like terms
 
3. assigned checks to actions, leading to discovery of the requirement for a state_is(subject,state) check. more on that later.
 
4. ran test case for state_is(subject,state) for the various combos of subject and state, generating a list of possible quests that were not lame and made sense.
 
5. ran test case of using generated list in multi-part quest template. worked ok.
 
6. ran test case of creating a quest series at random from last quest to first quest, using generated list. worked ok, but almost all links between quests were of the form reward=location of next questor, due to test case chosen. the test case was a game where you can't get unique item A to activate unique item B to kill unique boss monster C, because there aren't unique items or monsters (yet).
 
7. listed types of prerequisites's for the generated list: one location, one location of object, all others: location of questor.
 
8. compared generated list to existing quests in the current and previous versions of the test case game. identified an additional 3 actions, 1 object type, and 1 state variable required to implement all quests in all versions of test case game using the new system. so the system seems to be able to handle all cases, assuming the game supports it.
 
9. ran test case for generating list of quests from actions and objects. worked ok, seems easier than by subject/state. almost all prereq's are still @questor location though.
 
10. listed prereq's for all combos of action/object. all but player goto are @location questor, as player goto location is the only quest in the test case that's not you doing something FOR some one. prereq for player goto location is: the location to goto.
 
11. determined that "special items/powers" are needed for "get A, to do B, to kill C" type quests. IE to get prereq's other than @questor location, such as "player has special item A".
 
12. determined that "using special item/ power" is a modifier that adds a "player has special item/power" prereq to a quest.
 
13. started analyzing modifiers.  need a definition of "don't get caught", it might be assumed.
 
 
next post:
details on the new state_is(subject,state) condition check.
0

Share this post


Link to post
Share on other sites

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:

 

 

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)
 
is_known(what,by_who) = has(subject,object) where object=information
 
exists(subject)=has(subject,hp_left)
 
has(subject,object) = state_is(subject,in possession of object)
 
time_expired(deadline)=state_is(time,deadline)
 
at_location(who/what, where)=state_is(subject,@location)
 
from my notes:
"ok, seems to have boiled down too far. we're left with the obvious conclusion that all condition checks are of the form:
state_is(subject,state)
which can encompass time clock past deadline, subject has object, subject at location, and subject exists."
 
skipping ahead a bit:
"so its looks like we can't look to the condition check type to generate our quest from, as all quests use nothing but various forms of the state_is(subject,state) check.
so we must look to the subject and state to draw up tables of types of quests.
for subjects we have persons, places, and things.
for states we have: some variable at, above, or below some value.
 
variables can include:
hit points (exists, is alive, is dead or destroyed)
other stats or skills, including relations
inventory (stuff you can carry)/ownership (stuff you can't)
is_prisoner (Boolean)
has_info (Boolean or perhaps some list of info known).
location
a state variable such as is_kicking (used for checking combos)
 
well that's very general and vague...
what to do with it?
to apply it to a game, you'd list the possible types of subjects ... and the [state] variables that make sense [to check]"
 
I then tried that on the game i'm working on. results were OK, but doing it based on actions and objects seemed easier. Doing it based on actions and objects also yielded a list of ALL types of quests that made sense for the game, as opposed to only those types that the game engine currently supported in the way of state variables.
 
 
 
 
 
 
0

Share this post


Link to post
Share on other sites
so here are the lists i'm working with now...
 
ASSUMPTIONS:
1. players are expected to defend their party and it's posessions at all times, this includes quest items to be turnd 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).
 
QUEST ACTIONS:
1. attack/destroy 
2. defend
3. transport
4. acquire
5. influence/convert
6. use/interact with
7. successfully execute (do something [combo/trick move])
8. be guinea pig.
9. unique actions germane to the specific title (in case we forgot anything)
 
"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.
 
I added "unique title specific actions" just to be safe.
 
OBJECTS:
1. person/NPC/friendy unit or monster/badguy/hostile unit
2. item/ including special/unique quest items
3. information/orders
4. landmark, location, building (a fixed position).
5. combo/trick maneuver
6. stat/skill/exp/special power, etc
in general: a person, place, or thing.
 
MODIFIERS:
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)
3. no killing (non-lethal only)
4. methods of aquisition: make, steal, take from dead opponnet, find, gather, buy, blackmail/coercion
5. Don't attack (Not even non-lethals are allowed)
6. time limit/window
7. using special item / power etc. usually the special item / power is one time use only.
 
CHECKS:
1. state_is(subject,state) where subject is basically any variable in the game, and state is some value , range, limit, etc.
 
PREREQUISITES:
1. player knows location. transport(subject,location) where player is already in posession of subject. transport(player,location), a goto() quest, appears to be the most common type of quest with this prereq.
2. player at questor location. this is just about all quest types.
3. player has special quest item(s)/power(s). for "get A, to unlock B, to kill C" type quests.
 
So now i'm down to:
what's the definition of "don't get caught" and is it already implied in any quest that might use it?
 
Did I miss anything in the lists?
Did I take out anything that should have been left in?
Did I add anything that doesn't belong there?
2

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0