• 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

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"

0

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.

 

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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)

0

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites

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.

 

but unless you get into generating components of the back story, you're limited to like one screen of mission orders worth of the SAME copy (or boilerplate)  for ALL quests of a given type.

or you get the madlibs effect: Journey to the (location), there you will find the lair of the (monster). Use the (special item/power) to defeat the (short name of monster). Do this, and I, (name of questor), shall bestow upon you (reward).

 

location: Isles of Shanarsa

monster: Ancient Kolug-bouk Troll of the Dwarven mines

short name: Ancient Troll

special item/power: Mirror of Medusa

name of questor: Kalgar, Overlord of Valentia

reward: a fiefdom in the fertile fields of the Western Marches

 

once you plug in the madlibs it doesn't sound so bad:

 

"Journey to the Isles of Shanarsa.  There you will find the lair of the Ancient Kolug-bouk Troll of the Dwarven mines.  Use the Mirror of Medusa to defeat the Ancient Troll. Do this, and I, Kalgar, Overlord of Valentia, shall bestow upon you a fiefdom in the fertile fields of the Western Marches."

 

Can you tell I used to be a DM? <g>.

0

Share this post


Link to post
Share on other sites

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.

 

unfortunately, i'm the writer. doesn't phase me though. i've learned how to turn out decent copy over the years as needed. with sufficient "madlibbing" each backstory can be made to seem at least semi-unique. but usually only that. as the player runs more and more quests of a given type, they'll eventually detect the patterns.

0

Share this post


Link to post
Share on other sites

Stormynature:

 

on the 36 types of stories:

 

a quick glance revealed they're all tragedies.

 

are all quests tragedies? never thought about it. whats your take on that as a writer?

0

Share this post


Link to post
Share on other sites

Stormynature:

 

on the 36 types of stories:

 

a quick glance revealed they're all tragedies.

 

are all quests tragedies? never thought about it. whats your take on that as a writer?

 

Sorry Norman, I should have thought to let you know that this is merely one type of breakdown. There are in actuality a large number of opinions as to basic plot devices and archetypal characters. What I was essentially doing was providing you with one literary point of view of how plots are atomised (or rather - simplified rather than atomised) as I thought it might be useful to you.

Edited by Stormynature
0

Share this post


Link to post
Share on other sites

Sorry Norman, I should have thought to let you know that this is merely one type of breakdown.

 

yes, i noted that while checking out the site. i found it most interesting that muitiple attempts by different persons at different periods in time yielded the same or similar results, and that the list has been in publication since 1916 (as i recall).

 

time to start checking into natural language processing.

 

do you think it might be possible to generate a story line first, and then use that as input for generating the associated campaign?

 

seems to me a "plot" would be picked at random. this would define things like characters, locations, objects, etc. which are then generated. the "plot" would determine the action, possible objects, possible mods, etc.

0

Share this post


Link to post
Share on other sites

do you think it might be possible to generate a story line first, and then use that as input for generating the associated campaign?

 

You might then also want to pay attention to how Choose your own Adventure stories are structured as this would be somewhat inline with your thinking as well. Though Servant has covered this to a degree with earlier posts imo.

0

Share this post


Link to post
Share on other sites

You may also wish to give consideration to the creation of false quests i.e. the story teller tells a story but the details are wrong/created/quest is already completed. As well red herring quests (subsection covers video game examples). While it can be a source of frustration to the player it can also be an excellent timesink...as well you can always add in elements that contribute to quests not yet obtained.

0

Share this post


Link to post
Share on other sites

a test case:

 

from the 36 dramatic situations:

 

 

  1. Crime pursued by vengeance
    • a Criminal; an Avenger
    • The Criminal commits a crime that will not see justice, so the Avenger seeks justice by punishing the Criminal.

 

let's keep it simple: player (avenger) kill person who wronged them (criminal).

 

action: attack/destroy (specifically: kill)

object: the criminal

modifiers: none

checks: success if criminal dead

rewards: none, other than the satisfaction that the criminal is no more.

 

orders: Kill "John the Ass".

 

it gets tricky here. there has to have been a wrongdoing on the part of the criminal towards the player BEFORE the quest encounter.

 

ok, well lets assume that the game engine can track this somehow.

 

in fact, we may need to define another assumption:

* its assumed that the game engine implements all features and tracks all info required for a valid quest type for a given title.

 

so our game engine "knows" what the wrongdoing was.

and the existence of a wrongdoing made it possible to generate this type of quest in the first place, as the wrongdoing is a prerequisite for this type of quest.

so when the questgen rolled the dice, first it said, "do we have wrongdoing? ok, use this table that includes quests with wrongdoing as a prereq then". and the die roll came up "player (avenger) kill person who wronged them (criminal)".

 

so we can use this extra info to improve the orders:  "The time has come for you to eliminate John the Ass, who most treacherously wronged you by (whatever the wrongdoing was)".

 

but its still boilerplate copy:

the time has come for you to eliminate (criminal), who most treacherously wronged you by (the crime).

 

i don't see a way around this.

 

even the list of 36 dramatic situations looks like a bunch of templates.

 

the goal is to have the PC randomly generate everything, so even the developers won't know what's going to happen next in the game when they play.

 

so there won't be a tool that generates quest scripts that a writer then uses as a start for writing a hard coded quest or campaign.

 

there will just be the quest generator that does it all, including the copy the player reads. so all the good back story and "why" stuff a writer would add needs to be randomly generated, or omitted.

 

actions, objects, modifiers, etc are enough to define goals and orders. so additional back story is technically unnecessary. 

 

but going back to the above example, unless you have a table of reasons "why" now is the time to kill (criminal), or something like that,  i can't really think of a good way to add back story.

 

and the 36 situations don't seem to address this, unless i'm missing something. they're more like a detailed list of the types of tragic quests possible. They will probably be a great starting point for generating quest types, but we're still left with fleshing out the story line using only the features and variables the game uses for quests, and random generation, with no human intervention. IE making randomly generated quests seem like they've been authored by a writer. 

 

but the problem is that every time you complete a "destroy object" quest, you get the boilerplate success message of "You (destroyed) the (object)!".

 

about all i can think of is you have like 10 boilerplate messages saying the same thing and pick one at random:

1. You (destroyed) the (object)

2. The (object) has been (destroyed)

3. With great valor, you have (destroyed) the (object)

and so on...

 

any ideas?

 

i have none at the moment.

 

I think i'll implement the generator for just one very basic quest type (perhaps just in pseudocode on paper) , and see what happens once i get down to the orders part.

 

but in all my years building games, i've never seen a good solution to generating back story for quests. that's the one part of DM'ing that computers just aren't good at yet. They can generate dungeons, and encounters, even world maps pretty well. but stories....

1

Share this post


Link to post
Share on other sites

You may also wish to give consideration to the creation of false quests i.e. the story teller tells a story but the details are wrong/created/quest is already completed. As well red herring quests (subsection covers video game examples). While it can be a source of frustration to the player it can also be an excellent timesink...as well you can always add in elements that contribute to quests not yet obtained.

 

 

yes, yet more types, or perhaps modifiers. up to this point, we've mostly been talking about straight forward quests where there's no dishonesty, deceit or subterfuge involved. actually, these many be "twists" of straight forward quests.

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