Questless exploration
Goto page 1, 2  Next
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Tue Mar 28, 2006 2:17 pm    Post subject: Questless exploration Reply with quote

It's hard to think up an appropriate title for this thread, so instead I'll try to describe what I mean.

The topic of classless advancement has come up many times over the years, along with the pros and cons it offers as compared with class-based advancement.

What I've been considering is applying the same approach to quests. A "quest" is often defined as a module containing a sequence of tasks - but what if we were to remove the modular concept and simply have a selection of interconnected tasks?

For example, imagine we have the following quests:

Quest 1: Rescue the dragon from the lusty virgin:
Task 1.1: Travel to the dragon caves and speak to the dragon elder.
Task 1.2: Travel to the village and steal the chastity belt.
Task 1.3: Give the chastity belt to the poor victimised dragon.

Quest 2: Protect the princess from her would-be lover:
Task 2.1: Travel to the silver fortress and speak to the king.
Task 2.2: Lead the princess to the Red Lion tavern.
Task 2.3: Prevent the would-be lover from entering the tavern overnight.
Task 2.4: In the morning, lead the princess to the golden fortress.


Is there really any reason for having the overall quest, rather than just the tasks? If we discard the overall quest and just have a sequence of tasks, each unlocking the next, then the end result is the same - but it also allows for some interesting crossovers between tasks.

For example, completing task 1.2 (stealing the chastity belt) before task 1.3 could allow you to skip task 2.3. On the other hand, another task (assassinating the king of the silver fortress) might disable the 2.1 task and open up a new 3.1 task (sneak into the silver fortress and kidnap the princess) which also enables task 2.2.

The only real advantage I can see of the modular approach is one of organisation - it makes it easier for players to keep track of what they have to do. But it also makes the quests feel like a series of unrelated activities, rather than parts of a whole. I think it could provide a more immersive feel if many of the tasks were heavily interconnected.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Tue Mar 28, 2006 6:26 pm    Post subject: Reply with quote

In the minds of the NPCs, the important thing a player did was the quest, not the final step in the quest. So if you want the player to be treated as "the guy who saved the dragon", you either need an overall quest or you need to mark the final step as a special reputation-building step labelling him not as "the guy who gave the chastity belt to the dragon" but as "the guy who saved the dragon". I don't know that functionally there's much difference between the overall-quest and the special-subquest; that reputation is effectively just a reward for the subquest anyway.

You might be able to get away with fewer bits of storage attached to each player if you lump the pieces into quests, and you only track the subquests separately for quests that are ongoing. This is perhaps not important in this modern era of free disk space and memory.

Finally, you might find it easier to manage if you have quests. Say that Joe has somehow gotten his quest completion history screwed up and you need to go in there and fix it: that would probably be easier if Joe has marked down a hundred quests in various states than if he has a thousand quest-parts.

It seems like neither approach necessarily limits the functionality if implemented properly - you can certainly make a system where quests can have crossover bits used in other overall quests.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Tue Mar 28, 2006 9:23 pm    Post subject: Re: Questless exploration Reply with quote

I've got something frightfully simple. So simple it may be stupid.

Every object has a unique id. And by object I mean room, monster, object, script, everything. Successful "use" of any object invokes the following:

score |= 1 << obj.id

score is an infinite length bit string.

puts "You have scored #{score.bits} out of #{score.size*8} possible."

There you go. That's the entire quest system in a nutshell. Wink
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Tue Mar 28, 2006 10:19 pm    Post subject: Reply with quote

That seems like a valid way to store quest completion info. It's certainly simple to implement.

Memory usage isn't a problem: on a big, old mud, there are an awful lot of unique things, but even so your bitvector might reach 10k or 20k bytes, and such sizes can be thrown around with abandon.

You can't have a single "thing" that marks two quests completed, at least not without creating a dummy thing to represent the second quest. And then you have violated your design, and will cry.

It's sort of clumsy to work with, because there probably isn't a good name associated with most of the bits. There is no doubt some sort of name, but a room name or "lecherous ogre's fourth script" isn't going to be easy to interpret for the programmer. Of course you can associate more useful names with the bits, but once you start doing that, then you could just forget about the bits entirely and have a hash table of the names instead.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Wed Mar 29, 2006 12:01 am    Post subject: Reply with quote

I'm still not sure I completely understand the distinction, but, based on my present interpretation, I would argue that the core aspect of questiness you need to maintain for a modular, task-oriented approach is a goal-orientation. That is, to take a page from open-ended CRPGs and Deus Ex, player's are primarily motivated by their target objective. That objective may be to protect the poor lass or innocent dragon, or to destroy the enemy keep. Objective is one extremely effective (and possibly primary) way they and the NPCs will organize and group quests.

Consider this... it's long been noted that most quests in computer-based rpgs have components derived from a small set of equivalence classes. There's the Fedex task, the kill X task, the find X task. This may be most clear in World of Warcraft. However, the core concept that distinguishes the quest from a series of tasks is the setting - it has a preamble, a goal, and probably a reward, with maybe other aspects of story in-between.

CRPGs often use step-by-step, task-by-task approaches to quests. Thus, even more open-ended ones will still have a very visible task approach. An example in point may be KotoR (if I remember it correctly, it's been a while). While you may have a major quest ("Stop the sand people raids."), it's broken down into tasks. And while multiple branches are available, they're coded in such a way that the present task often shows up in your quest log (kill guy X, save guy Y, etc). By the same token, if you do certain tasks, others become unavailable. Slaughtering a bunch of characters could include slaughtering someone involved in a later quest (maybe less common in Bioware games, but very common in Troika games). Coherence is achieved by the storytelling aspects, the reward aspects, and the overall organization by major goals. Interaction betweeen tasks and interoperability are achieved by offering multiple methods to complete an objective and making the availiability of the methods contingent on previously chosen methods.

On the other hand, you could take a Deus Ex style approach. Slap down a goal, throw in random storytelling aspects, and then let the player figure out how to get from A to B. In this case, you achieve coherence by giving the player only one primary organizing principle (the goal). Goals may conflict, but that's another story. In the end, they generate the tasks, and as such, will intrinsically situate and add value to the task within the framework of their goals. Interaction and interoperability is emergent, in this model.

Further, goals are the primary organizing principles for players and characters anyways. That is, if you check out game development theory (and, in truth, much of HCI), you'll find that a recurring theme - goal hierarchies. Basic premise (much simplified) is that the user needs something to aim for in the next second, next minute, next hour, next day, next year. This is clearly not ALWAYS true (sandbox systems are a counterexample), but it's proven very effective for most systems. Thus, I argue that players already organize quests along goal-driven lines, not task-driven.

Further, NPCs organize quests along similar lines. I would not give you my daughter's hand in marriage just because you managed to acquire a bunch of items that could be used in freeing her from her temporal imprisonment... I'd maybe give you her hand in marriage if you actually saved her. However, would that result be fundamentally different if you saved her by tricking her prison's guard? casting a bunch of arcane spells? forcing her captor to free her at sword-point? It's the end goal that offers an opportunity for reward and reputation.

For all my talk about coherence, this would extremely incoherent. I apologize. I'm still not completely clear on the topic... and, I'm also trying to figure out if I see any fundamental distinction between a modular and non-modular quest approach (presently, I don't think there is). So, sorry it's all confuzzling (and more sorry if it's not really on topic!)
Back to top
View user's profile Send private message
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Wed Mar 29, 2006 10:30 am    Post subject: Reply with quote

I'm not sure how helpful it is to distinguish between a "quest", a "task" and a "subquest". I think arguing about them may make things less clear rather than more.

I very much like the idea of having an overall objective, and giving the player a reasonable degree of freedom in how he decides to achieve it. I also very much like the idea of making quests interdependent: a crude example would be that if you rescue the dragon, you incur the undying wrath of the princess' family, and thus lose the opportunity to be gainfully employed as a spy by her father, but gain the opportunity to do some fetch-and-carry work for the dragon elders.

But there are some practical, technical problems with this.

First, if the method of completing a quest is relatively open-ended, you need to be very sure that you have anticipated all possible player solutions to it. Suppose a task involves releasing a prisoner from a cell in order to create a distraction that will allow the player to obtain the quest objectobe without being interrupted. Rather than going through the hassle of slaughtering a jailer and stealing the key, an enterprising player might cast an invisibility spell on the prisoner through the bars of the cell, thus making the guards think that the prisoner has escaped when, in reality, he hasn't. Your detection of whether or not the task is complete really needs to be sophisticated enough to recognise the casting of the invisibility spell as a viable solution to the task. It may be quite difficult to anticipate all the possibilities a really twisty player might come up with.

Along the same lines, you may need to allow for players deciding they don't actually want to complete the quest. Suppose an NPC hires the player to deliver a letter, and warns that his enemy may try to intercept it. Suppose the player decides that he would much rather work for the opposition, heads off for the opponent's keep, and hands over the letter. Is the quest code able to handle that?

Second, as already mentioned, the more complicated the inter-related tasks become, the more likely it is that something, somewhere along the line, will go wrong; and the harder it will be to untangle when it does.

Third, this sort of structure is much easier to handle in a single-player game (I also thought of Deus Ex Smile ) than it is in a multi-player environment. To a degree, this applies to quests generally: if, while the player is off searching for the Belt Of Hiccup Curing, some other player slaughters the hiccuping NPC who issued the quest, how do we handle that? But this gets much worse in a situation where there are multiple, inter-related tasks: one action by another player can block a path that should have led on to dozens of different tasks rather than just one. In general, handling a structure this complex in an environment that is dynamic and can be altered in unpredictable ways by other players is much harder than a similar system in a one-player game with a managed story-line.
Back to top
View user's profile Send private message
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Wed Mar 29, 2006 2:26 pm    Post subject: Reply with quote

Spazmatic wrote:
Consider this... it's long been noted that most quests in computer-based rpgs have components derived from a small set of equivalence classes. There's the Fedex task, the kill X task, the find X task. This may be most clear in World of Warcraft. However, the core concept that distinguishes the quest from a series of tasks is the setting - it has a preamble, a goal, and probably a reward, with maybe other aspects of story in-between.


Hmmm that's something I'd not considered, but I see your point - break the quest down into independent core components, and the tasks are likely to feel far more repetitive than they would if they were integrated parts of a quest.

shasarak wrote:
Third, this sort of structure is much easier to handle in a single-player game (I also thought of Deus Ex) than it is in a multi-player environment. To a degree, this applies to quests generally: if, while the player is off searching for the Belt Of Hiccup Curing, some other player slaughters the hiccuping NPC who issued the quest, how do we handle that?


Well depending on the mud, and what the quests represent, you could potentially handle it in the same way as a single-player game - allow each player to perform their own version of the quest, without interfering with each other. Or you could do it Diablo2-style, allowing players to effectively "invite" friends to help them.

That wouldn't work for all muds of course (I can already hear the cries of "The 'MU' in 'MUD' stands for 'Multi-User'!) but it's certainly a viable option, particularly if it's only one aspect of questing ("personal objectives" or something).

I also don't think it's necessary to take into account every possible solution, although if you're careful you can usually cover most of them. If the objective is to steal something from the chief jailer, for example, then I would simply make that the task. It's then up to the player whether they want to cause a distraction, free the prisoner, sneak past, or simply kick down the door and butcher everything in sight - the task simply requires them to obtain the item, it doesn't care how they get it.
Back to top
View user's profile Send private message Visit poster's website
Author Message
ide



Joined: 21 Feb 2006
Posts: 105
Location: Seattle

PostPosted: Wed Mar 29, 2006 4:28 pm    Post subject: Reply with quote

shasarak wrote:

if, while the player is off searching for the Belt Of Hiccup Curing, some other player slaughters the hiccuping NPC who issued the quest, how do we handle that? But this gets much worse in a situation where there are multiple, inter-related tasks: one action by another player can block a path that should have led on to dozens of different tasks rather than just one.


Very good point, and instancing quests for one character only is a way to handle that, but to me it takes away some of the fun of mucking up somebody's quest (i.e. my quest is to derail your quest!). So how do you still make it fun for the player whose quest got mucked up?

I think the quest writer needs to put an additional layer of abstraction over the entire quest system. Take your rescue the prisoner example. Why does the prisoner need to be rescued? Maybe he's a leader of the revolution, and the revolution needs him for morale and his strategic leadership. So the revolution doesn't just need the prisoner, they need the qualities of the prisoner, and you can generate literally dozens of 'also-prisoners' if you know what the important qualities are. If the prisoner meets an untimely end your quest system moves on to the next quality-instance.

If it's not the token that's eliminated but the token machine (the hiccuping NPC), well...tough luck. Crying or Very sad Seriously, it's reasonable to think there's another hiccuping NPC out there (especially if it re-pops, right?), or maybe there's another use for the belt.

You could run into the problem of generating instance after instance and some players getting frustrated that they're not having an affect on the game world, so maybe you need to taper the relative strength of the quality after n instances.

Spazmatic wrote:

Thus, I argue that players already organize quests along goal-driven lines, not task-driven.


One thing I like about quests as interdependent parts and not modular stories is that players can sort of make their own quests from the parts that interconnect. This also takes advantage of the generally non-linear nature of mudding.

You could organize these custom quests as threads with tags on their parts, and the tags are categorized under one or more goals. For example, your PC completes part 1.2, 1.4, 2.1, and 2.2, tagged greed, honor, respect, and betrayal respectively. Each tag might also have a volume, maybe 1.2 was just a little greedy, but 2.1 was very respectful. Of course these parts are really the 'solutions' to the parts as they've been described before. I'm not sure of the best way to organize the threads, however, and maybe this represents a flaw in the plan; perhaps you simply chronologically arrange parts that are interconnected, so you could have a part in more than one thread if it connected to more than one other part.

What you end up with is a player with many quest threads, each thread telling a general story about the character, the player can see their character developing one way or another. I think this will act as positive feedback to make story lines more coherent (more coherent than my example). In general I like an explicit display that describes a character's history, maybe other people prefer a less heavy-handed approach.

OK, before I wrap up this ramble, I want to add one more thing -- if you already have quest parts, abstract instances, and customized story threads, I'd like to see an additional layer of something you could call quest generators, meta-NPCs, quest managers. Just like players could develop reputation and social histories with in-game NPCs and other players, quest actions could develop quest histories between parts of the game world and these meta-NPCs, leading to more coherent random quest generation. I like the idea of quest machines but dislike them in practice, maybe this would be a way to make them more meaningful. Of course it could spiral horribly out of control and all of a sudden you have 102874 bundles of herbs to find in the Gloomy Forest and return to Abraxisisfis the alchemist, but surely you could eliminate that possibility in your design, right? Smile
Back to top
View user's profile Send private message Send e-mail
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Wed Mar 29, 2006 4:41 pm    Post subject: Reply with quote

Quote:
First, if the method of completing a quest is relatively open-ended, you need to be very sure that you have anticipated all possible player solutions to it.


No, as this is a game world. Players need to operate within the world's limitations. As long as you're consistent (that is, not adding special NPC scripts on a per quest basis), you'll be okay.

Consider Deus Ex or Deus Ex 2. They both had terrible AI, bizarre object models (DX2 Havok was hilarious, while in DX1 I could kill people by throw boxes on their heads and getting them stuck), and, often, some very strange task completion detection rules that meant certain approaches didn't work.

However, Deus Ex is considered the paterfamilias for the entire emergent gameplay clan, and is arguably its greatest achievement. Simply put, players learned what the system could or could not handle, and worked within said limitations.

(I include Thief 3 because, if you've played it, you'll know it has the world's greatest sound propagation model that takes into account materials and angles in excruciating detail. However, while the best ever, it's still a limited approximation, and has notable issues when dealing with windows and the like. Yet, the system limitations tended to provide more gameplay opportunities than limits, as you could abuse the faults to create interesting situations.)

Quote:
Along the same lines, you may need to allow for players deciding they don't actually want to complete the quest.


If they don't want to complete the quest, they don't have to complete the quest. If they want to help the opposition, well, that's too bad. We don't have to support that, by any means. Simply put, the opposition could be too cruel, too stupid, too self-involved, etc, to want the player's help.

No world is perfect and complete. I've always thought an easy way to complete "Destroy the elven shrine in the Glimmering Forest" type quests was to start a forest fire. I've yet to see a game allow that (okay, TA and Battle Realms sort of did... but those are RTSes).

Quote:
To a degree, this applies to quests generally: if, while the player is off searching for the Belt Of Hiccup Curing, some other player slaughters the hiccuping NPC who issued the quest, how do we handle that? But this gets much worse in a situation where there are multiple, inter-related tasks: one action by another player can block a path that should have led on to dozens of different tasks rather than just one. In general, handling a structure this complex in an environment that is dynamic and can be altered in unpredictable ways by other players is much harder than a similar system in a one-player game with a managed story-line.


Let's assume your world is static. (The worlds I've been working on in years past are mostly dynamic and persistent. That's a whole different and ugly can of worms.)

If so, then mobs repop. Items reappear. Things reset. That, in and of itself, is not going to be the problem. If you use stable forms of quest information storage and individual quests (that is, everyone can save the woodsman from the hooded red rider), then this shouldn't be any harder than a singleplayer equivalent.

By stable forms of information storage, I mean, don't store quest information on mobs that will be lost when they die. Don't create quest mobs only when players trigger something. Allow players not to carry on some mystical "I killed it" flag, but rather to carry around an item. In fact, if you want really fine examples of information storage and persistence, check out WoW. They did a GREAT job of this. Just fantastic.

As far as other players interfering in your quests, in a fairly traditional world, I don't see the problem. If they kill a critical NPC, they repop, no?

Quote:
the task simply requires them to obtain the item, it doesn't care how they get it.


You'll want to make the item un-tradeable between players, of course. Razz

Quote:
break the quest down into independent core components, and the tasks are likely to feel far more repetitive than they would if they were integrated parts of a quest.


And it also becomes unclear how anyone (NPC or PC) should benefit from them.
Back to top
View user's profile Send private message
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Wed Mar 29, 2006 11:55 pm    Post subject: Reply with quote

I didn't notice your post, ide, before I posted my last reply, so here you go.

Quote:
I think the quest writer needs to put an additional layer of abstraction over the entire quest system.


The way you describe it, this is precisely a goal-driven approach. A quest exists in so much as some goal needs to be accomplished. How you accomplish that goal is irrelevant. You may have lost access to a subquest (ex: rescue the rebel champion), but you could instead take his place and lead the rebels on to victory. The secondary goal is gone, but you still complete the primary goal, and the peasants rejoice.

However, there are some issues with this. First, eventually, your goal structure breaks down. This is especially problematic with hand-built systems. Planning agents for goal-systems help alleviate this issue, but it's still there. Second, it's hard to handle too many alternative approachs. I consider excessively tiered goals to be unnecessary if you're developing a traditional mud (repops, etc) rather than a fully consistent, persistent one.

Quote:
You could run into the problem of generating instance after instance and some players getting frustrated that they're not having an affect on the game world, so maybe you need to taper the relative strength of the quality after n instances.


I do not understand what "relative strength of the quality" means. Elaboration would be helpful.

However, as far as frustration with not impacting the game world, how is that different from any other (non-GM run) system out there? I'd love to have players be able to truly improve the world around them, but that requires a dynamic, persistent, self-evolving world, and that's a can of worms you do not want to open.

Quote:
One thing I like about quests as interdependent parts and not modular stories is that players can sort of make their own quests from the parts that interconnect.


How is that a "quest" then? It's a set of tasks someone connected together. Without some preamble or goal, the tasks are just tasks. Without Hera, Hercules' 12 Tasks were just 12 ways to gain experience and get uber loot. In the game world, nobody gives a rat's arse if you ran around and did 1.1, 3.2, 4.3, and 78.94 if it didn't help anyone... why would the baker care, if you didn't get him his secret ingredient? That's what I mean by goal-oriented. Without goals, the player can imagine he or she's questing, but it completely fails to interact with the game world and becomes little more than quest masturbation.

Quote:
You could organize these custom quests as threads with tags on their parts, and the tags are categorized under one or more goals. For example, your PC completes part 1.2, 1.4, 2.1, and 2.2, tagged greed, honor, respect, and betrayal respectively.


What you're describing is character analysis. There are better ways to do this than just tagging some tasks, but, that's not entirely the point. It's basically a data mining problem - what do the character's choices and actions tell us about him or her?

However, this doesn't make it a custom quest. Killing 100 geese and then killing 100 cows doesn't make it a quest... it tells me that the character has some animal rights issues, but not much else.

Let me create a little example.

Goal-oriented:
Farmer Fred wants you to protect his crop from all them rabbits and, er, coons that keep eating it. So, you go and kill 100 rabbits. You gain some experience from the combat. You go and kill 100 coons. You gain some experience from the combat. Farmer Fred's not too happy about your solution, but, hey, that's life. He gives you some coin, some corn, and the shovel of extra digging. You gain some experience for completing the quest, and you gain the reputation: "ide, protector of farms."

Task-oriented:
You kill 100 rabbits. You gain some experience from the combat. You kill 100 coons. You gain some experience from the combat. You gain the reputations: "ide, butcher of rabbits." and "ide, butcher of coons."

Which do you prefer?

And, I can't make heads or tails of that last bit about "meta-NPCs". Either some definitions or elaboration would be helpful.
Back to top
View user's profile Send private message
Author Message
ide



Joined: 21 Feb 2006
Posts: 105
Location: Seattle

PostPosted: Thu Mar 30, 2006 1:49 am    Post subject: Reply with quote

Spazmatic wrote:


ide wrote:
You could run into the problem of generating instance after instance and some players getting frustrated that they're not having an affect on the game world, so maybe you need to taper the relative strength of the quality after n instances.


I do not understand what "relative strength of the quality" means. Elaboration would be helpful.


The quality is the important descriptor of the quest token (the prisoner, the key, the 100 rabbits). Relative strength is their importance in the context of the goal, for example the imprisoned rebel leader is very important, but if you take the reins of the revolution, you are not as important.

Spazmatic wrote:
However, as far as frustration with not impacting the game world, how is that different from any other (non-GM run) system out there?


Sorry, I wasn't quite clear, I meant frustration in the sense that you want to disrupt Froodo's quest, and you keep disposing of the quest tokens he needs, but the mud re-instances them over and over, so your efforts are useless. However if each instance was not as useful/important to Froodo, then your actions are effective.

Spazmatic wrote:
Without Hera, Hercules' 12 Tasks were just 12 ways to gain experience and get uber loot. In the game world, nobody gives a rat's arse if you ran around and did 1.1, 3.2, 4.3, and 78.94 if it didn't help anyone... why would the baker care, if you didn't get him his secret ingredient? That's what I mean by goal-oriented.


Of course, given no explicit quest modules it's possible for a character to never 'complete' a quest, but it seems unlikely, and this speaks to your very amusing farm quest example, which seems more of an exception than a rule.

Additionally if the character doesn't complete the farm quest, that says two things, either the player didn't have the ability or the time to do it, or the player didn't want to do it, but did want the character to kill all the animals. In the former case I admit the tags, character goal/story system breaks down. In the latter case the tag system (I should say I don't mean to suggest a tagging system is the be-all and end-all) works very well, because the character is described as a bloody animal killer, or whatever depending on the mores of your game world.

On the other hand it's true I was thinking of goals more in the sense of character life goals, and less in the sense of in-game story goals (i.e. quest completion).

Spazmatic wrote:
And, I can't make heads or tails of that last bit about "meta-NPCs". Either some definitions or elaboration would be helpful.


C'mon, I'm not allowed to just throw 'meta' around without any explanation? I thought that was the reason people used that term. OK, what I meant was, given a system that tracks PC and NPC interaction, the NPC develops knowledge of what the PC is/does and can react accordingly. The meta-NPC is not an in-game (IC) object but a system object that tracks what the PC is/does, and in its meta layer can also interact with other meta-NPCs to create, that is generate, new quest parts. A meta-NPC doesn't have to be a character, it's really a non-player object. It could be a character, a geographical location, an emotional state, an environmental state. Perhaps this additional layer is unnecessary, you could do the same thing with IC NPCs, but I thought it might be better to keep this part of the mechanics separate, and the abstraction (representing the Gloomy Forest as an object, say) would be useful.
Back to top
View user's profile Send private message Send e-mail
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Thu Mar 30, 2006 8:45 am    Post subject: Reply with quote

Quote:
Goal-oriented:
Farmer Fred wants you to protect his crop from all them rabbits and, er, coons that keep eating it. So, you go and kill 100 rabbits. You gain some experience from the combat. You go and kill 100 coons. You gain some experience from the combat. Farmer Fred's not too happy about your solution, but, hey, that's life. He gives you some coin, some corn, and the shovel of extra digging. You gain some experience for completing the quest, and you gain the reputation: "ide, protector of farms."

Task-oriented:
You kill 100 rabbits. You gain some experience from the combat. You kill 100 coons. You gain some experience from the combat. You gain the reputations: "ide, butcher of rabbits." and "ide, butcher of coons."


Well that's not really what I had in mind...imagine breaking the quest into the following:

Task 1: Find and talk to Farmer Fred - he asks you to protect his crop.

Task 2 (requires task 1 to be complete): You kill 100 rabbits and gain some experience.

Task 3 (requires task 1 to be complete): You kill 100 coons and gain some experience.

Task 4 (requires 2 and 3 to be complete): Speak to Farmer Fred again - he gives you the shovel of extra digging and you gain the reputation: "protector of farms."


Well, those could be handled as tasks without being encapsulated into a quest, and by doing so you could also add the following:

Task 5 (blocks tasks 1 and 4): Kill Farmer Fred. Lose the reputation "protector of farms", gain the reputation "not to be messed with".

Task 6 (requires 1, blocks and blocked by 4 and 5): Speak to Farmer Joe - he asks you to destroy Farmer Fred's field.

Task 7 (requires 6, blocks 8): Destroy Farmer Fred's field. Gain a reward from Farmer Joe.

Task 8 (requires 6, blocks 7): Warn Farmer Fred about Farmer Joe. Gain a reward from Farmer Fred.

Task 9 (requires 8): Kill Farmer Joe. Gain the reputation "vigilante".

Task 10 (requires 5): Speak to the assassin's guild, get access to a range of new tasks, and the possibility to learn assassin skills.

Task 11 (requires 9): Speak to the batman guild, get access to a range of new tasks, and the possibility to learn vigilante skills.

Task 12 (requires 10 or 11): Speak to the mercenary guild, get access to a range of new tasks.


And so on...

Assuming that the activities were instanced, or in some other way prevented from being spoiled by other players, this would end up doing what Ide described - each player would end up with their own thread, and their own story.

It's not as nice as unique human-run quests, but it's a little less static than the traditional prewritten approach - it wouldn't be the case that everyone had helped Farmer Fred, for example.

This story approach could also be tied in with character advancement, much like some muds do for character creation (as a kid, did you a) ..., b) ..., c) ...). For example in order to learn assassin skills you might have to perform tasks which bring you to the attention of the assassin's guild. Other abilities might only be learnable by performing tasks (eg the mad alchemist teaches you how to brew love potions in return for some favour or other).
Back to top
View user's profile Send private message Visit poster's website
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Thu Mar 30, 2006 4:52 pm    Post subject: Reply with quote

Quote:
The quality is the important descriptor of the quest token (the prisoner, the key, the 100 rabbits). Relative strength is their importance in the context of the goal, for example the imprisoned rebel leader is very important, but if you take the reins of the revolution, you are not as important.
...
Sorry, I wasn't quite clear, I meant frustration in the sense that you want to disrupt Froodo's quest, and you keep disposing of the quest tokens he needs, but the mud re-instances them over and over, so your efforts are useless. However if each instance was not as useful/important to Froodo, then your actions are effective.


Hmm, interesting. It does seem to offer up a problem, though, in that it's a system essentially designed for griefers. If you offer up the ability to a) impact a specific player's quest, and b) to continuously degrade it (perhaps to a finite extent, but still), I see a system solely used by griefers and severely dangerous for newbie happiness. However, if the system was designed so that quests could interrelated and have (short-term) impact, I could see an interesting level of interaction between players. Ex: the evil priests quest involves killing the good priest, who is a quest dispenser and trainer for players. Thus, players in the process of questing or training would try to defend the good priest, and if the evil players got him, then the good players would be kinda screwed for a while. Nothing permanent, like reducing the value of their quest xp.

Quote:
Of course, given no explicit quest modules it's possible for a character to never 'complete' a quest, but it seems unlikely, and this speaks to your very amusing farm quest example, which seems more of an exception than a rule.


The two examples weren't supposed to be in the same system, but rather the first was a goal-oriented system, and the latter was (at the time) what I took to be KaVir's system. He has since clarified that.

Basically, without goals that correspond to the NPC world and the player's world, you fail. The first is important because that's how the game can understand quests. The latter is important because that's how players can understand them. Character life goals, as you bring up further down, fall under the latter category.

Quote:
...meta-NPC...


Hmm. I see. So, basically, you want a quest engine. It really doesn't seem to have anything to do with meta-NPCs or what not. More... a planning agent, or perhaps a classifier combined with a planning agent. Latter, probably.

I think quest planning has come up before. If not here, than on TMC or TMS. There was some question about whether it should be the role of powerful NPCs (which has the advantage of making the world terribly self-consistent), or an immterial quest engine (which has the advantage of designing quests per player), or both (allowing the former to control wars and the latter to handle "Help the woodsman" quests).

Quote:

Well that's not really what I had in mind...imagine breaking the quest into the following:
...

Well, those could be handled as tasks without being encapsulated into a quest, and by doing so you could also add the following:
...

Assuming that the activities were instanced, or in some other way prevented from being spoiled by other players, this would end up doing what Ide described - each player would end up with their own thread, and their own story.
...

This story approach could also be tied in with character advancement, much like some muds do for character creation (as a kid, did you a) ..., b) ..., c) ...). For example in order to learn assassin skills you might have to perform tasks which bring you to the attention of the assassin's guild. Other abilities might only be learnable by performing tasks (eg the mad alchemist teaches you how to brew love potions in return for some favour or other).


Isn't that, more or less, the system used by every Troika and Black Isle and Bioware rpg? We're not so much breaking things into tasks, as offering the player goal choices that branch into separate quests (or subquests, whatever). I'll give an example further down.

The key to making them quest-like and rewardable, though, is that they fit into the world. You don't get rewards just for killing rabbits. You also don't get rewards for killing rabbits when nobody wants you too, even if they did before. And, you probably wouldn't kill said rabbits if nobody wanted you too. The fact that you can make a choice to side with different factions isn't an inherent product of task-orientation, but of goal-orientation.

I don't see your split as being the real split in the system. Rather, I see the following:

Goal 1: Farmer Fred wants you to protect his crop.
Reward: Shovel.

Goal 2: Farmer Joe wants you to destroy Fred's crop.
Reward: Cropburner.

Goal 3: Warn Farmer Fred.
Requires: Goal 2.
Reward: Tail of a tattle.

I left off the reputations, because upon further examination, I believe a reputation engine is inherently separate from a quest engine. (Consider the "not to be messed with" quest. Or, consider Arcanum, in which slaughtering Stillwater for a quest gets you the "Butcher of Stillwater" reputation, but if you slaughter them on your own, you don't, which is absurd.)

I also left off the guild-ness. I also think that's somewhat separate (though, some games do have fully quest-driven guild membership... like, say, Morrowind). Rather, guild admission seems to be driven by your actions. Joining the fighter's guild would require they believe you to be a good fighter, ala you fight a lot. It's doubtful that's all that contingent on whether you're fighting for a quest or not.

I, personally, was discussing a system like this when I was discussing goal-oriented design. This is especially true if you want to make them dynamic (planning agents, rawr). This is also a system that's everywhere... KotoR may be the most famous example. Morrowind has bits and pieces of it too. I played Arcanum recently, and I think it has all the pieces... quests that interrelated, counter each other, skills (or, in its case, master training) that is dependent on quests, quests that may or may not show up (i.e. kill Farmer Joe for vigilnate-ism), reputations, etc...

I'm not sure, still, where I see this "thread" business. It's really just a bunch of decisions (if you have a static, non-generative model). I take one branch, you take another. Nodeka, I believe, tries to track this with some morality scores (poorly, though, from what I saw). CRPGs track it too, sometimes sort of (KotoR gives you the whole dark-side light-side bit, for example). In the end, though, unless you're generating things on the fly, it's just a matter of a few decisions, and limited content (one of the main reasons why people don't implement the system).
Back to top
View user's profile Send private message
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Thu Mar 30, 2006 7:58 pm    Post subject: Reply with quote

Quote:

Memory usage isn't a problem: on a big, old mud, there are an awful lot of unique things, but even so your bitvector might reach 10k or 20k bytes, and such sizes can be thrown around with abandon.


Nods. It's ~13K per character per 100000 objects. That may become a concern. On the disk storage side, most characters will have long runs of zero bits, so streaming it with zlib might be useful.

Quote:

You can't have a single "thing" that marks two quests completed, at least not without creating a dummy thing to represent the second quest. And then you have violated your design, and will cry.

It's sort of clumsy to work with, because there probably isn't a good name associated with most of the bits. There is no doubt some sort of name, but a room name or "lecherous ogre's fourth script" isn't going to be easy to interpret for the programmer. Of course you can associate more useful names with the bits, but once you start doing that, then you could just forget about the bits entirely and have a hash table of the names instead.


Well the thing is, why do you need names? Is the builder consciously designing a quest called "Rescue the Elfin Princess"? Is the existence of that quest known beforehand to the player?
Or answering KaVir's question, "Is there really any reason for having the overall quest, rather than just the tasks?"

Let me describe how a "quest" might be created by a builder not consciously even creating a "quest". Actually the birth of a mud. Now assume a world with no objects without form, and void; and darkness is on the face of the mud.

* Enter Tyche. I'm object #000. Yes, I've bootstrapped myself from outside the mud universe by leaping off the back of a stack of turtles that exist in the 11th dimension. 1 point (I mean to suggest that the universe is worth 1 point - Tyche floating in the void - picking his nose).
* I dig a room (2 points)
* I make an exit, call it a door, I make a key (3, 4 points)
* I hide the key in the room, and set the exit to that key.
* I build another room and link it to the exit I made (5 points)
* I set an enter script on the room which on failure causes an an anvil to crush the player. (mostly likely kill any player who picked a hobbit) (6 points - that is success doesn't release the anvil)
* I make a sword, put it in the locked room. Name it ElfFriend. (7 points)
* I make a plump elfin princess. She's in the void with Tyche, probably being violated. (8 points)
* I make a speech script on sword ( If the holder says 'xyzzy', the plump Elfin Princess lands in the room, at an extremely high rate of speed and explodes on impact. A voice booms "You have rescued the Elfin Princess! You rock!" - 9 points)
* done

Player Bob (10 points) connects and lands in starting room.
Welcome Bob!
You are in a room. There is a door on the orsten wall.
Exits: orst
> score
Bob you have scored 2 points out of 10 possible.

Hmmm.. Very Zork-like. What are the tasks, the steps, the quest?
Is the feedback triggered above by holding the sword and saying "xyzzy" the players reward?
Are the points?

What are the "use" conditions? How does one "use" a room and score points? I define it as successfully entering the room. There's an interesting side effect of this. I can generate a local map for the player knowing exactly where they've explored. The score bits double as the players map.

How does one "use" a player and score points? One rather interesting way is to use it as an introduction system. Every player you meet and introduce yourself to, you get a point for. The score bits double as a social map.

Interesting side effects. I mean less the overlapping implementation but the reward for social and spatial exploration.

Okay maybe players would be befuddled or lost by not having a list of quests presented to them. Maybe they want bonus points. That's easy enough to add. That requires the builder to register a name in a table somewhere and call some sort of function at the completion of the quest.

quest_complete(qname, bpts)
self.accomplishments << qname
self.bonus_points += bpts

So the speech script on the sword calls
quest_complete("Rescue the Elfin Princess", 100)

Obviously builder's will consciously design quests, probably even map them out on paper and all the relationships between the objects and monsters and what not. Smile

ObEdit: Oh and yes every object has a name. I could name that sword script, "Rescue the Elfin Princess", assuming one wanted to link success of that to some other quest.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Thu Mar 30, 2006 9:20 pm    Post subject: Reply with quote

The quest names make it easier to debug quests; also easier to look at somebody and see what quests they've done in a digestible form. And generally yes, the builder IS consciously designing a quest called "Rescue the Elfin Princess". And when some other builder is later designing another quest and would like to require that you've accomplished some earlier goal made by somebody else, it's easier for him to track down the one he wants if they all have good descriptive names, and also if what he thinks of as a "quest" isn't scattered over ten different bits in a bitvector. So says I.

Anyhow, you appear to warm to the idea of the name later in your post. So, I still don't understand once you have the names, what do you still want the bits for? The one-to-one mapping between "accomplishment bits" and objects seems strained; this is the cause of your dithering over the concept of "use". Because what if I can use an object several different ways? Ok, maybe there are actually different scripts handling the ways and so it's technically different objects (script objects), but what if I can use an object one way but the results and thus the appropriate accomplishment bits depend on some inherent property of myself?

Exploration-based bonuses are very nice, in fact we have them in Sloth, but I implemented them as separate from quests. (As with most diku derivatives, our world is divided into named areas; the first time a player visits an area and also the first time he kills something in an area, he gets about 2% of a level's worth of experience points; every player carries around a list of the names of all the areas he has ever visited, and a separate list for areas-where-he-has-killed). You could certainly store one bit per room per player, why not, there's lots of nice stuff you can do with that, but it doesn't appear to me that that necessarily has anything to do with quests or subquests.

And even in that case, why limit yourself to a bit? On Sloth we store scent trails, so whenever a person passes through a room it makes note of the time and the person and which way he was coming and going, then later a druid shapeshifted into a dog, for example, can track him by scent. (Ok, that gets big after a while, so we only store the most recent I think 50,000 such events). (Of course, since there are more effective magical ways of tracking people, nobody ever does that, sniff.)
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign