...Bringing the best of MUDs and online text gaming to your browser...


Forum

You must be logged in to post


Register? | Lost Your Password?

Search Forums:


 






Wildcard Usage:
*    matches any number of characters
%    matches exactly one character

Dynamic Quests – What's the State of the Art

UserPost

12:32 am
September 16, 2008


Fuseboy

New Member

posts 5

1

I was a fairly successful coder/builder on a CDLib MUD, Angalon, years ago, but have been out of serious mudding for years.  As many do, I've nurtured a lot of nostalgia for it, and I've had the urge to get back into it.

Anyways, I've been sitting on a few ideas that were inspired by some recent play in EVE Online.  The quest instancing was neat, but it seemed so basic, and it seems like there's room to do way, way more.  I hear a lot about how MUDs are in many ways more advanced than their graphical cousins, game-play wise (as it's easier to build, say, faction support when you don't have to deal with all the graphical stuff that goes along with it).

Has anyone done anything where quests, or "the plot" more generally, is entirely dynamic?  Where each quest solved permanently changes the world?  Or anything along those lines?

I'm curious what the state of the art is before I go and reinvent the wheel.

7:12 am
September 16, 2008


lspiderl

Member

posts 17

2

Not sure myself as i've only reccently returned to the mud comunity myself ,however it seems to me that it would require building multiple versions of entire zones ( or atleast the effected areas)

and having one zone coded to replace the other after a certain quest was completed

idk jstu my thoughts off the top of my head

5:23 pm
September 16, 2008


Fuseboy

New Member

posts 5

3

Well, no, that's not really what I had in mind.  You could do that, but it would be a heck of a lot of work!  Imagine something more like this:

You enter a village; the priest sits on the steps of his little church.  Sizing you up as a hardy type, he beseeches you to help restore the chalice that was stolen by bandits.  You do this deed, and return the chalice.  He is grateful, but offers no reward.  This pisses you off, so you kill him.

The villagers are incensed and attack you, but you flee from them and escape elsewhere.  Word reaches you much later, however, that the villagers have had their local lord declare you an outlaw.

Meanwhile, the village has no priest.  Another player wanders through.  The villagers size him up as a hardy type, and ask him if hewould take word to the bishop in the city that they require a priest, which he does.

A few weeks later (of game time, perhaps a day or two real time) a newly ordained priest is set to take his post as the village's priest.  The road is dangerous, however.  He sizes up a nearby player, who looks a hardy type, and asks him if he will escort him out to the village.

Etc. etc.

8:49 pm
September 16, 2008


Molly

4dimensions.org 6000

Member

posts 17

4

The main problem is that very interactive quests, and also Quests with multiple choices and several possible outcomes, need a lot more work than the traditional Quest, which goes its due course, similar for every player that tries it. And since building and scripting already is very time consuming, you have to take that into cosideration when you design Quests. However much you'd like the quest to be different for for every player, it just isn't feasible. The same goes for one-time-only Quests. However desirable those may be in theory, they are a waste of work and bandwidth. (And the players usually hate them too, especially if the reward is an item that you cannot retrieve if you've already done the Quest).

So you have to settle for something that is doable with a resonable amount of extra work. One very obvious thing is, that even if a repeatable Quest doesn't change much itself the second time you do it, the reward certainly should. A Quest is only hard the first time, so the reward must drop drastically after that. Another basic thing is to add some random elements, (to stop the 'blabbing' about the solution between players, and to add some new twist, even when it's repeated by the same player). I use tricks like making the scripts check for the players Race, Class, level, align and even stats like int, wiz and charisma etc.,  and then send the players on different paths dependant on that.

Many of our larger Quests are set up in several steps, and all the Questmobs involved will interact differently with you dependent on what stage you are in the Quest. (This is easily done with flags set on the player file).

One thing that I also like to do, is to cater for the players who don't just always do the obvious.

An example: Mob A is plotting some scheme against Mob B, and sends you with a letter to Mob C, to seek his assistance against the enemy. 9 players out of 10 will of course faithfully deliver the letter to C, and get rewarded or sent on a further mission by him. But the 10th player, who thinks along unusual lines, might find it interesting to see whet Mob B would do if you brought the letter to him instead. This should lead to Mob B either rewarding the player for the unexpected info, or recruiting him/her as a personal ally,  which in turn would trigger a totally different twist to the same Quest.

I don't think many Muds cater for options like that, but I try to do it myself, if possible. It can lead to far more interesting Quest plots – and of course, every good Quest should always have a background story and a plot.

But, like I stated in the beginning, it all depends on how much time and effort you want to spend on something that only a small part of you     r playerbase might actually discover and savour.

Molly O'Hara of 4 Dimensions

9:21 pm
September 16, 2008


lspiderl

Member

posts 17

5

Molly said:

The main problem is that very interactive quests, and also Quests with multiple choices and several possible outcomes, need a lot more work than the traditional Quest, which goes its due course, similar for every player that tries it. And since building and scripting already is very time consuming, you have to take that into cosideration when you design Quests. However much you'd like the quest to be different for for every player, it just isn't feasible. The same goes for one-time-only Quests. However desirable those may be in theory, they are a waste of work and bandwidth. (And the players usually hate them too, especially if the reward is an item that you cannot retrieve if you've already done the Quest).

So you have to settle for something that is doable with a resonable amount of extra work. One very obvious thing is, that even if a repeatable Quest doesn't change much itself the second time you do it, the reward certainly should. A Quest is only hard the first time, so the reward must drop drastically after that. Another basic thing is to add some random elements, (to stop the 'blabbing' about the solution between players, and to add some new twist, even when it's repeated by the same player). I use tricks like making the scripts check for the players Race, Class, level, align and even stats like int, wiz and charisma etc.,  and then send the players on different paths dependant on that.

Many of our larger Quests are set up in several steps, and all the Questmobs involved will interact differently with you dependent on what stage you are in the Quest. (This is easily done with flags set on the player file).

One thing that I also like to do, is to cater for the players who don't just always do the obvious.

An example: Mob A is plotting some scheme against Mob B, and sends you with a letter to Mob C, to seek his assistance against the enemy. 9 players out of 10 will of course faithfully deliver the letter to C, and get rewarded or sent on a further mission by him. But the 10th player, who thinks along unusual lines, might find it interesting to see whet Mob B would do if you brought the letter to him instead. This should lead to Mob B either rewarding the player for the unexpected info, or recruiting him/her as a personal ally,  which in turn would trigger a totally different twist to the same Quest.

I don't think many Muds cater for options like that, but I try to do it myself, if possible. It can lead to far more interesting Quest plots – and of course, every good Quest should always have a background story and a plot.

But, like I stated in the beginning, it all depends on how much time and effort you want to spend on something that only a small part of you     r playerbase might actually discover and savour.


um … marry me ?

lol

on a more serious note though thats a ton of work but would make for some amazing and fun quests

if you ever need a job let me know ;)

4:03 am
September 17, 2008


Fuseboy

New Member

posts 5

6

Molly, thanks for the considered response.  It sounds like you've been making some interesting quests.  If I understand you, yes, that would be a lot of work!

I think I'm after something slightly different – maybe the term 'quest' brings connotations I'm not meaning to imply.

What I'm trying to work out is a sort of plot improvisation engine.  So, instead of coding up a specific quest, I'm thinking of a system that would be able to dynamically compose "atoms" of plot-related NPC behavior onto cohesive stories, on the fly.

By atoms of plot-related behavior, I mean concrete things like, "issue verbal thanks", "give small cash reward", "recognize", or "ask player to carry message".  (Despite being concrete,  these are still 'uninstantiated', and unconnected with any particular player or NPC.)

It's not hard to imagine ways in which you could compose these into weightier behavior sequences, such as ordering an underling to dispense a some gold trinket from the treasury as a reward.

Now consider, separately, the idea of NPC 'motives'.  These are persistent impulses to meet some objective, but in an unspecified way.  An example might be, "demonstrate gratitude to <x>", or something as simple as "kill <x>".  You could imagine the system selecting behavior sequences that fulfill these motives, somewhat randomly, somewhat on the basis of the NPC's resources.  An desperate beggar might satisfy his motive to kill you by dropping his crutches and trying to strangle you in the street (via the "heedless physical attack" sequence).  The king might simply order someone to do it for him (via the "delegate to trusted killer" sequence).

Back to the plot improvisation engine.  Make a bigger leap with me and imagine the engine is always running, always looking for ways to fulfill NPC motives not just randomly, but in a way that engages specific players.  This would be based on player stats, accomplishments, affiliations, and also his or her declared 'story goals'.

One player might be looking for combat challenges, another for courtly intrigue, for example.  If the knight pisses off the king, then contrive him a plot where the king's favourite challenges him in combat.  If the courtier gives offense, then subject him to character assassination.

In fact, how much better if the assassin is himself a player!

So, that's the idea in a nutshell.  Rather than ever composing specific quests, write plot elements that can be randomly composed into bigger potential stories by the thousands, scored for suitability, and the best chosen and put into play.

The ultimate goal is to create a world with an evolving plot, where NPCs are constantly pushing dramatic potential, but where all "denouments" are carried out by players.

6:26 pm
September 17, 2008


Fizban

Member

posts 14

7

Here's a simplistic example but it's something that could easily be done on tbaMUD.

You complete a quest, let's say hmm, killing 100 goblins in a cave. 

From this point on whenever you see a goblin it runs screaming from you if there are less than four goblins in the room. If there are four or more they feel safe in numbers and all attack you at once.

That is doable, in fact, easily doable in tbaMUD (The Builder Academy MUD, code-wise it's essentially CircleMUD but being developed by a different group of coders than the original due to Jeremy Elson having retired) and wouldn't require all that much work, whereas having a village be different for different players depending on what they've previously done, that is utter hell.

Oh and sorry lspiderl, but you can't have my Head Builder. (Okay technically the MUD is more hers than mine, but she's the Head Builder and I'm one of the coders so maybe that makes me her coder, but she's the closest anyone comes to being my Head Builder.)

8:25 pm
September 18, 2008


lspiderl

Member

posts 17

8

Fizban said:

Here's a simplistic example but it's something that could easily be done on tbaMUD.

You complete a quest, let's say hmm, killing 100 goblins in a cave. 

From this point on whenever you see a goblin it runs screaming from you if there are less than four goblins in the room. If there are four or more they feel safe in numbers and all attack you at once.

That is doable, in fact, easily doable in tbaMUD (The Builder Academy MUD, code-wise it's essentially CircleMUD but being developed by a different group of coders than the original due to Jeremy Elson having retired) and wouldn't require all that much work, whereas having a village be different for different players depending on what they've previously done, that is utter hell.

Oh and sorry lspiderl, but you can't have my Head Builder. (Okay technically the MUD is more hers than mine, but she's the Head Builder and I'm one of the coders so maybe that makes me her coder, but she's the closest anyone comes to being my Head Builder.)


awww maybie we can share ;)  lol

12:23 pm
September 20, 2008


Orrin

Admin

posts 139

9

I am not aware of anything as sophisticated being used in a MUD, nor in any other online games for that matter. I think the main limitation is technical – what you describe would be very difficult to do effectively and in the case of MUDs is probably far better handled with real people. It's probably a similar thing to chat bots, they have been around for years and we often hear how sophisticated and lifelike the next one is, yet they are not widely used in games because they never seem to be realistic enough for players. I expect a system you describe would suffer from similar flaws, infact in some ways I wonder if the more realistic a system appears to be, the more frustrated players may get if it doesn't meet their expectations. I imagine it would be very difficult to design a system that could cope with every choice that players may make.

Traditionally in games this kind of thing has been handled by staff taking over NPCs at certain times to interact with players and create dynamic plots themselves. Some games even have a 'think' command that the player can use to notify the staff of their character's intentions. The staff then have an idea of what kind of roleplay the player is looking for and can then decide whether to animate an NPC to interact with the character. I expect that given the small scale of most MUDs this kind of dynamic plot generation is quite practical and probably more satisfactory than trying to procedurally generate it.

I wish you luck with it, and it's definitely an area I am interested in,  however right now I think the scope of the problem is too vast to attempt to tackle for my own game so it's on the 'nice to have' list for when more essential stuff is done.

1:19 pm
September 20, 2008


Kunin

Seoul, South Korea

New Member

posts 8

10

Not to sound like a plug, but one of our (almost complete) planets has some pretty nice quests that fit the discussion.

IG Story:

Some hundred years ago, a ship crashed into Jekrito whilst running away from the Empire's authories. Descendents of some half-breed refugees(Human/Brotick) have made their lives on this Planet, which they called Jekrito. They eventually spread out into two tribes, the ones who had more Brotick features, calling themselves Omok, and the ones who had more human features calling themselves Imor.

The Omoki people took to the grasslands of Jekrito, living as nomads, always moving as a group. They herded the cattle animals in the Aughskele Grasslands, using them as a source of food, materials for shelter and trade these with the Imori people.

The Imori people settled at the foot of the Ildaugh Hills, working the fertile soil into a rich farm. The two tribes lived and dealt with each other quite amiably.

Some years, a ship of Corsair humans landed and changed the two tribes life forever. They enslaved the young people and took them away, leaving the tribes in fear, and despair.

Today, join the Corsair humans in their slavery trade of the Imori and Omok, or, convince them that you seek to help keep their youths safe, by hiding them far away from the Corsair Camp.

On the planet you can do various quests, for all three factions, which (along with other things, such as killing their members) can change how they view your character.  Over time one side may take to you more, offering you new quests to either help free the slaves or enslave more of the locals.

The amount of free people in each village, as well as the number of slaves in the Corsair camp, has an effect on the amount of commodities each side produces.  These are sold via commodity shops, as well as tithed to the Empire that controls the planet.  If the Corsair trust you enough they can even enlist your aide in transporting some of the slaves (males only) to their nearby base on the moon Jemok, where the male slaves will be put to work in the mines.

There is a total of around 200 possible slaves/locals that are part of the quests, which does show in the number of mobs on each side (if they have more slaves, there are more slave mobs and less local mobs).  The entire slave process can be shut down as well, which involves getting the locals to trust you a lot and another series of quests.  If it is shut down there is a matching quest, starting on Jemok, to restart the slave trade.  The controllers of Jemok also gain tithes from the Corsair camp on Jekrito, so if different Empires each control one of the planets there would be an obvious (unless both think slavery is bad) fight over the slave trade.

Killing slaves, or locals, can lead to "nuetral" mobs running around that help neither side.  If you are trusted enough to help capture slaves, or free them, then you can round up these nuetral mobs and bring them back to the side you are assisting.

Obviously there's a bit more to the quests here, but I think it's a good example of the types of dynamic quests that can be done with a decent mobprog/script system in most MUDs.  This particular one has been in the works for a little over a month now (just the scripting part) and should be 100% within a few days.  I agree a lot with Molly that adding dynamic elements to your areas really helps it feel more alive, and you should always think about the "out-of-the-box" concepts as well (killing the slaves/locals was one that we originally didn't think about, but modified later to add another element to the planet without giving one side a clear advantage).

Producer, Tears of Polaris

3:05 am
September 21, 2008


Fuseboy

New Member

posts 5

11

Again, thanks for all your feedback.  Well, yes.. it's potentially very broad, and it's possible that what I've described contains five separate sub-problems each of which are only solveable with real AI.  And, even if it works, it's possible that the whole thing turns out not to be any less labour intensive than hand-writing a gigantic MUD because of the sheer effort in writing templates for places, personalities, cultures, etc.

Add to this the issue that I think it would also involve writing a MUD engine (or heavily rewriting one).

But, I'm still curious, and time permitting I'll chip away at it.

10:27 pm
December 19, 2009


jaunt

Chicago

New Member

posts 3

12

Digging up this old post, to give some input. I think that, as a designer, getting away from the concept of what constitutes a "quest" is a good idea. I've scripted events that include things such as player-controlled armies handled in an almost boardgame-like manner that affect enemy and friendly NPC numbers … building projects that allow players to gather supplies and spend time building a tower that was then a full area of its own upon their completion … an automated search+find and then potion-making quest to find the ingredients for a giant spider's venom with a timer for the event, which a catch – failure would mean the death of an actual Player Character … environments with dangerous npc wildlife based entirely off of destructable and hidden monster spawning nests, so that player patrols to scout, find and destroy enemy strongholds have a direct affect on the safety of the wilderness … raiding/protecting farm-land to affect food production for both your side and the enemy's side … and many other such things.

Automation can be a great thing. It allows you to make your game as immersive as you would like through scripting and AI, without needing to rely on heavy admin interaction. It can also let you give a chance for your players to affect the world around them (it's not hard to make buildings be vulnerable to PC arson, or to let PCs build unique structures of their own with tie-ins to localized economy). These can be traditional quests (MMOs), non-traditional quests (Four Dimensions), or they can be tied into the very fabric of the gameworld. In particular, I think that the latter works very well for immersive games that focus on deep roleplay. It's become one of the most important staples which I use in design over the past few years, and I am constantly finding that, yes – you can dig deeper and go further with "quest" gameplay.

Atonement RPI: The Next Generation in Storytelling RPG – http://www.atonementrpi.com



About the MudGamers Forum

Most Users Ever Online: 16

Currently Online:
7 Guests

Currently Browsing this Topic:
1 Guest

Forum Stats:

Groups: 3
Forums: 10
Topics: 250
Posts: 668

Membership:

There are 621 Members

There is 1 Admin

Top Posters:

Brody – 93
Fire – 53
Gotrek – 50
KaVir – 25
Lyanic – 22
Vladaar – 18

Recent New Members: barbeekorross, yola_nation, dogma, barrasueegorull, mdesmond13, lucestar

Administrators: Orrin (139 Posts)