Jump to content

  • Log In with Google      Sign In   
  • Create Account

Types of quests


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
55 replies to this topic

#21 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
1Likes
Like

Posted 18 February 2013 - 11:37 PM

- 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, 18 February 2013 - 11:43 PM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


Sponsor:

#22 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 20 February 2013 - 05:58 PM

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.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#23 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 21 February 2013 - 10:55 AM

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.
 
 
 
 
 
 

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#24 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
2Likes
Like

Posted 21 February 2013 - 01:53 PM

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?

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#25 sunandshadow   Moderators   -  Reputation: 5073

Like
0Likes
Like

Posted 21 February 2013 - 03:27 PM

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?


Phone game idea available free to someone who will develop it (Alphadoku game - the only existing phone game of this type is both for windows phone only and awful. PM for details.)


I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.


#26 Servant of the Lord   Crossbones+   -  Reputation: 21213

Like
0Likes
Like

Posted 21 February 2013 - 03:57 PM

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"


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#27 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 23 February 2013 - 06:40 PM

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.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#28 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 23 February 2013 - 07:07 PM

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.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#29 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 23 February 2013 - 07:35 PM

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.

 
7. determined campaigns should be generated from last to first, generating branches, loops, and split paths as needed.
 
8. determined basic variables required to track a campaign.
 
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.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#30 Stormynature   Crossbones+   -  Reputation: 3423

Like
1Likes
Like

Posted 23 February 2013 - 07:47 PM

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 smile.png].

 

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


Edited by Stormynature, 23 February 2013 - 08:05 PM.


#31 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 23 February 2013 - 08:01 PM

In my last post i forgot to list:
 
9. determined that when a "using special item" quest is generated, a "get special item" quest is should be automatically generated to precede it, and the two quests together make up that stage of the campaign.
 

 

 

here's the list of variables to track a single quest that I came up with:

action

object

modifiers

object data

mods data

 

 

 
here's the list of variables i came up with to track a campaign:
1. a list of stages.
2. for each stage:
  A. type (single quest, split/merge, loop, split, or multiple-simultaneous).
  B. info about the quest(s) in that stage. only multiple-simultaneous stages will have a list of quests. all other have one quest per stage.
  C. "on success" and "on failure" next stages. these are used for the branching in splits, split/merges, and loops. for all others, they both have the same value, whatever the next stage in the campaign is.
  D. probably need a "current _quest" var to track where they are in the campaign.
 
 
 
 
here's the stage templates i came up with:
1. single quest: success quest A -> next stage.
2. 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.
3. loop: success A -> next stage. failure A -> complete zero or more stages before you can attempt quest A again. this provides mission flow that loops.
4. split: success A -> stage 1. failure A -> stage 2. where stages 1 and 2 are different branches of a branching story line campaign. this provides mission flow that branches.
5. multiple-simultaneous: 2 or more single stages that can be completed in any order to advance to the next stage in the campaign.
 
 
here's the method of generation i came up with:
so to generate quest using action/object method:
first you make your tables:
1. make list of actions valid for the game in question.
2. make list of objects valid for each valid action.
3. make list of modifiers valid for  each valid action/object combo.
 
to generate a campaign, you first generate the number of stages on the main path from quest encounter to final reward. 
campaigns are generated from last stage to first stage. 
if a split stage is generated, the length of the branch that splits off the main path must be determined, and those stages generated, perhaps with a flag set indicating that its a branch off the "main path", so the final reward should be lower (1/2 treasure for example). 
if a split/merge stage is generated, the "sidetrack" stages for it need to be generated
if a loop stage is generated, the stages in the loop need to be generated.
 
put it all together, and you have a quest gen system that will do all kinds of neat mission flow. 
 
the question is, is it possible to generate the "why" they should do such and such, as opposed to simple orders than can be derived: "kill rufio" orders follows from action: destroy, object: rufio. "why kill rufio" other than for the reward, is another can of worms.
 
perhaps "why" is not needed. in the oblivion "rufio" quest, they don't ever say why. in fact they explicitly say its not important.
 
orders, conditions, and prerequisites are all pretty self evident once you've generated action, object, and modifiers. but i'm wondering if the orders will sounds too contrived, or too "generated" ?

Edited by Norman Barrows, 23 February 2013 - 08:45 PM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#32 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 23 February 2013 - 08:44 PM

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.

 

AND what can be generated.   : (

 

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

 

cool, a test case.

 

ok, kill dragon. initial quest encounter occurs at tavern. first quest: find guy who found orb. second quest: find merchant. third quest:  get location of dragon from noble. 4th quest: kill dragon, get treasure. so far, so good, works as expected. the orders:

1. find guy who (supposedly) knows where dragon is.

2. find merchant who (supposedly) knows where dragon is.

3. get location from noble

4. kill dragon, get treasure

 

this is what i was talking about with the difficulty of generating "Why". once you get into the details of reasons, motivations, and by what means, quests become less generated and more hard coded (less replayable). the orb of vision is "why" these people know where the dragon is, but its just context to give the campaign a pretext for making you do whatever the quests are. Its the kind of color that is difficult to add with random generation without seeming contrived. the whole interactive story / story line generation thing. its the context provided in hard-coded campaigns and quests that makes them not appear generated. and the lack of context in generated campaigns that makes them appear generated. about the only way i ever found to reduce this effect was with the politics engine in SIMTrek / SIMSpace. the politics engine provided the overall context for a campaign. why are you starting a defensive campaign? like the politics engine just told you, the klingons have invaded federation territory!

 

so as i see it, everything up to now is pretty straightforward, and doable, albeit perhaps a bit complex.

 

the REAL challenge is getting a generated story line context to go with the quests, without seeming contrived, lame, or illogical.

 

not sure it can be done well. about all i can think of is generating random reasons "why" to do things. they would have to make sense, and a large variety of reasons would be required to make it not seem generated. 

 

i'm also not sure its required. nice but not required. how the questor comes to know the location of the dragon is interesting perhaps, but not required for mission completion.

 

But I _would_ like to be able to generate context if possible. basically we're talking about generating a unique story line to go with a campaign/quest. the campaign/quest is the "plot" or "theme", and defines some basic things like "setting" and "characters". I recently did some research on generating story lines, as i'm considering adding hard coded campaigns as well as campaign generators to my title, and was looking into story line generation as a means of increasing replayability vs hard coded campaigns. results to date in the field are not promising.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#33 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
1Likes
Like

Posted 23 February 2013 - 08:57 PM

edit: 36 Dramatic situations

 

hmm, what about starting with these, generating the STORY first, THEN generating the appropriate types of quests?

 

non-mission critical variables, such as who the specific bad guy is, could be generated to maximize the randomness of stories, helping to guarantee uniqueness.

 

sounds like i need to spend a day investigating that approach.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#34 Servant of the Lord   Crossbones+   -  Reputation: 21213

Like
2Likes
Like

Posted 23 February 2013 - 09:28 PM

Part of what can make quests interesting and not feel contrived, is building expectations and then breaking them.

Player is recruited to help defend a village from a group of bandits. As he's fighting the bandits, he realizes that the bandits are actually from another nearby village, and are trying to recover their stolen wives, children, and possessions that the village the player is defending stole from them.

 

Another thing that can make quests more interesting, is to give the player choices, and have the results of those choices carry real impact.

Player is recruited to help defend a village from a group of bandits (evil ones, this time). When the bandits attack, the player notices that one of the bandits is actually the person who murdered the player's brother. Seeing the player, that bandit takes to flight.

Player's choice: Chase the murderer down and get revenge, or stay and defend the village?

Real impact: The murderer gets away if the player stays and defends. Or, if the player gives chase, later when the player returns to this village, the entire village is burned down from the bandit attack. Consequences are final.

 

Another thing is, surprise the player, keep them on their toes so much that they don't see the cliches.

Player is recruited to help defend a village from a group of bandits. As the player and a few other mercenaries head towards the village, suddenly a dragon bursts out of the sky and attacks them. After an unexpected and intense battle, by the time they actually reach the village, the fight is already over and the village defended itself on its own with the mercenaries that did arrive on time. The player isn't paid by the villagers, since he didn't arrive in time to help.

 

As Stormynature said, once you establish the fundamental building blocks of the quests and realize how few there are, then you hand it over to the creative people who hide the limitations through artistic innovation in storywriting. Artists tend to rise to the occasion when faced with limitations.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#35 Stormynature   Crossbones+   -  Reputation: 3423

Like
1Likes
Like

Posted 23 February 2013 - 09:56 PM

The field you would be interested in pursuing self-generating stories would be Natural Language Processing.

 

Some links that may be of use to with regard story generation

http://grandtextauto.org/2006/09/13/the-story-of-meehans-tale-spin/

http://ijcai.org/Past%20Proceedings/IJCAI-81-VOL%201/PDF/004.pdf

http://www.eliterature.org/images/microtalespin.txt

http://grandtextauto.org/2007/10/30/scott-turner-on-minstrel/



#36 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 24 February 2013 - 07:35 AM

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)

 

yet another simplification.

 

do unique title specific action = successfully execute(title specific action)


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#37 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 24 February 2013 - 07:39 AM

Quest actions and modifyers can be unified:
QUEST ACTIONS | States instead of Actions [...]

 

here's the list i came up with when assigning checks to actions:

 

 

attack/destroy: state_is(tgt, dead)
defend: state_is(defendee,alive)
transport: state_is(transportee,@destination)
acquire: state_is(whoever,however many of whatever)
influence/convert state_is(subject,some level of relations)
use/interact with: state_is(object, activated)
do (combo): state_is(subject,doing move1) + ... + state_is(subject,doing moveN)
be guinea pig: state_is(guinea_pig,under the influence of the experiment)
unique actions germane to the specific title (in case we forgot anything): 
state_is(subject,unique title-specific state).

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#38 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 24 February 2013 - 07:57 AM

Part of what can make quests interesting and not feel contrived, is building expectations and then breaking them.

 

this might be handled with a modifier, or some internal flag that indicates that things are not as they seem. no, not that way. more like you have 2 versions of a quest, the regular version, and the "i'm on the wrong side" version. final conditions would be different, bit initial orders would appear the same, so you wouldn't be able to tell if you were playing the quest with the "plot twist" or not. 

 

I think "plot twists" will be key to maintaining variety. before i started this thread, i was starting to code templates for various types of campaigns. in those, i'd add optional plot twists such as: questor tells you where dragon is, but another party already has a head start on you.

 

odds are, certain types of plot twists like these will always be possible for certain actions. yet another component of the generator to be figured out. for each action, list possible plot twists. when generating a quest, check for optional plot twist and generate additional info as needed. the action will define the plot twists possible, and therefore the detailed info needed to execute the plot twist.

 

i find it interesting and elegant that so much info is encapsulated or implied by action, object, mods, and plot_twist_type.

 

actually, plot twists might be better handled at the stages level. more stuff to figure out.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#39 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 24 February 2013 - 08:03 AM

Another thing that can make quests more interesting, is to give the player choices, and have the results of those choices carry real impact.

 

this would require the effects to be modeled in the game engine.

 

in your example of kill badguy vs defend settlement, not a problem for my title. NPC's are persistent  and it tracks relations, so you can have an arch enemy. and settlements can be destroyed by attack. about the only thing it doesn't do already is make your arch enemy run away (until they're half dead).

 

this might be a type of plot twist, or perhaps a branch that depends on your choice.


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#40 Norman Barrows   Crossbones+   -  Reputation: 2402

Like
0Likes
Like

Posted 24 February 2013 - 08:29 AM

Another thing is, surprise the player, keep them on their toes so much that they don't see the cliches.

 

yes, i've used this technique before. its a plot twist thing. you have 2 or more versions of a quest. one is the regular quest: defend village, get paid. the others are twists: give orders for defend village quest, but actual quest is survive dragon attack. all the quests seem to start out the same, but they aren't. some have twists lurking  in their mission flow. the trick is to make the orders the same for the regular and twisted versions, so they all look the same at quest start.

 

a quick test of the system using your example:

 

we'll call this a dragontwist quest.

 

randomly determined quest type: dragontwist

quest template: you need the false quest (defend village, etc). you need the monster (dragon). the false quest needs a time limit.

running the quest: get quest encounter. show orders for false quest. at some point before time limit, trigger encounter with dragon. 

checks: failure (of false quest): time expired.

how it works: the player gets the quest encounter to defend the village. they must arrive at the battle before the dead line. then they encounter the dragon. the dragon encounter must take long enough to make them miss the deadline. this quest is basically a no-win situation. you must survive the dragon attack, but get no reward for doing so (except maybe dragon treasure). the "false" quest is designed to be undoable (insufficient time) and the player always fails it.

Note that "failure time expired" is the only check required. the player can never get to the battle on time, so no "success: village defended" check is required. no "dragon kills player" check is required, due to assumption 1: "the player is expected to defend their party and its possessions at all times". no "success: dragon dead" check is required, as there is no questor rewarding you for the dragon's death.

 

 

how does this type of quest fit in with what we already have? is it a new action or modifier or type of stage?


Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS