Questless exploration
Goto page Previous  1, 2
 
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: Thu Mar 30, 2006 9:45 pm    Post subject: Reply with quote

Quote:
We're not so much breaking things into tasks, as offering the player goal choices that branch into separate quests (or subquests, whatever).


Well perhaps it's more of a terminology thing. When I think "quest" I tend to think of it as a sequence of steps or tasks which combine together to form a small story-like sequence. I suppose in theory a quest might only consist of a single task (eg 'kill Farmer Fred'), but more likely it's going to consist of several (eg 'talk to Farmer Fred', 'kill 100 rabbits', 'kill 100 coons' and 'talk to Farmer Fred').

However from a design perspective, the multi-part quest will most likely still consist of a sequence of tasks taken from a small generic set. Thus the above quest might be represented by something like:

Task 1
Type: Talk
Target: Farmer Fred
Perform: 1
Requires: None

Task 2
Type: Kill
Target: Rabbit
Perform: 100
Requires: Task 1

Task 3
Type: Kill
Target: Coon
Perform: 100
Requires: Task 1

Task 4
Type: Talk
Target: Farmer Fred
Perform: 1
Requires: Task 2 and Task 3

Each quest would therefore consist of 1 or more such tasks (you could probably cover most possible quests just by combining tasks from a list of perhaps a dozen different types). The tasks themselves are pretty generic, but you could make them interesting with cosmetic touches.

However were you to drop the quest encapsulation, the objectives would remain identical - you wouldn't gain any benefit from killing rabbits (task 2) until you'd first spoken to Farmer Fred (task 1) for example, because task 2 requires you to have first completed task 1.

I suppose you could argue that each task would effectively be a small quest, but the important point (from a design perspective) is that each task would only have a single objective. It might still require some effort to complete that objective, and there'd be just as much cosmetic fluff as you'd have had were it part of a quest, but once you'd reached that objective (perhaps a specific number of times, such as for the rabbit killing task) the task would be completed and new tasks would become available.

Quote:
I left off the reputations, because upon further examination, I believe a reputation engine is inherently separate from a quest engine.


I think it depends on how you perceive your quest system - and this is another of the reasons why I'm trying to look beyond the artificial encapsulation.

A reputation system should be modified by your actions. Do good or bad deeds, and it should have an affect. Steal from someone, and you should be recognised as being dishonest. Kill your king, and the reputation should follow you for the rest of your life.

However these could be handled very easily with the aforementioned system - the king could have a 'Kill' type task on him, for example, while the 'steal' command could have its own task which is activated upon failure.

Not only would this save you the effort of creating a separate system for monitoring reputation, it would also have the advantage of being fully compatible with quests - kill the king and it might suddenly unlock access to new options, while at the same time modifying your reputation.

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


However these could also be handled through specific tasks. Perhaps a 'task' can be solved by demonstrating your combat skills in a number of different ways (including raising fighting skills to a certain point). Once again, this would then mesh seamlessly with the quest and reputation systems, allowing them to be used interchangably.

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


But each branch choice would effect your options, your reputation, and even the skills and abilities of your character. Your character (both in terms of what he can do and how others react towards him) would be based around the storyline you'd chosen to follow.
Back to top
View user's profile Send private message Visit poster's website
Author Message
shasarak



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

PostPosted: Fri Mar 31, 2006 12:07 pm    Post subject: Reply with quote

Two quick thoughts:

1) One way of avoiding some of the technical challenges of a huge network of interconnected tasks/quests would be to use a reputation system. The criterion for "Will the player be given the quest to recover the Lost Contact Lens Of Gnaarg?" therefore depends not on "Has the player completed the darklord sheep-stealing quest" but "does the player have a sufficiently high reputation with the darklord faction?" Any number of different tasks or actions might contribute to that value, including the sheep-stealing quest. This sort of system makes it less likely that the player will hit unplanned dead-ends, but still offers tangible progression from one task to another.

2) I actually rather like the idea of players being able to interfere with each other's quests, to the point where the quest becomes impossible to complete. If a player is given a quest to deliver a letter, and someone else is suposed to be trying to stop him delivering it, wouldn't it actually be rather more interesting if the opposition came from another player rather than only from NPCs?
Back to top
View user's profile Send private message
Author Message
kelson76



Joined: 27 Jun 2005
Posts: 30

PostPosted: Tue Apr 04, 2006 10:45 pm    Post subject: Reply with quote

So, I've been reading throught this thread and have a couple of thoughts...good to see a new topic up in the Design forum, it's been pretty quiet lately.

I don't know that thinking of it as a quest system really frames the issue correctly. The issue here is that in a typical MUD, the only things that are persistant are the characters, specifically stats and inventory. Everything else resets.

So, what we need is a generalized concept of 'points of persistance'. These are flags that are set on the character for specific actions that are taken and allows events to gain context.

A point of persistance has some specific attributes:

1. PoP Identifier
2. PoP Dependencies (Requirements or Exclusions)
3. PoP Modifiers (Align, Exp, etc)
4. PoP Flags (Repeatable, etc)


Example:

Kelson76 talks to Gil at the Inn, who suggests that he speak to Bart down at the wharfs to learn of a smuggling route into the city. Gill will let Bart know that Kelson76 will be stopping by to see him. (PoP 100 Set)

Kelson76 goes and talks to Bart at the wharf, if PoP #100 is set, Bart will show him the route, and maybe set PoP #203. If PoP #100 is not set, Gil hasn't talked to Bart on Kelson76's behalf, so Bart blows him off.

Kelson76 now has PoP #203 set, so he can go to the cliff at dawn and provide the secret signal that will open the secret door in the cliff to smuggle goods into the town.

The PoP dependencies can be much more than just an existing dependencies, but can also include exclusions, such as PoP #400 exists for Kelson76, so he is not offered an opportunity, etc and can never get PoP #467. This can be as complex as you want it to be, with internal AND and OR operations, allowing PoP's to be repeatable, put a counter on them which has effects, etc.

The idea is not to create a linear string of events in isolation, but to build a massive tree, which can result in a decision made at level 2 impacting what you have available to you at level 40. It creates an identity for the character.

However, I don't think that any of the PoP information should be available to characters. They should never know when a PoP is being set or used. This prevents them from becoming an easily traceable stat, but weaves it into the fabric of the game. There is nothing wrong with having a bunch of PoP's that build out a particular aspect of the players history having no effect other than logging decision points, at which the impact of those decisions is felt 20 PoP's down the road.

This can be used to create quests because they are just a linear set of PoP dependencies. You can be as strict or loose about the dependencies as the quest requires.

Also, you can assign a PoP modifier, which may grant you a certain amount of Exp, then turn off the repeatable flag, that way a player can't just repeat a quest over and over. Also, what I'm looking at is only basing alignment off PoP events, so by setting the repeatable flag to off, players can't swing their alignment every which way on a whim, but their alignment is built off the history of their character's actions.

- Kelson76
Back to top
View user's profile Send private message AIM Address
Author Message
Tyche



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

PostPosted: Wed Apr 05, 2006 3:23 am    Post subject: Reply with quote

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.


I understand about debugging, but not the latter. That's one if the questions I posed. Why a list of quests? And need players be informed that n quests exists named X, Y, Z, etc.? I'm thinking not.

Quote:

And generally yes, the builder IS consciously designing a quest called "Rescue the Elfin Princess".


Maybe. I know most map their ideas out, and do indeed plot and plan all the steps out.

Quote:

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.


The bitvector is implementation not interface. A builder would use either an object name or number from something previously created if they want to make dependencies.

Quote:

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?


Conceptually everything is about puzzle solving. I do have bonus points and ring bells and blink lights to give the player some feedback. I'm more partial to letting the players assign a name of their own to whatever "quest" they think they've solved.

Quote:

The one-to-one mapping between "accomplishment bits" and objects seems strained; this is the cause of your dithering over the concept of "use".


The nature of the game changes if you reward points for robbing/killing a player versus points for meeting a player, or points for exploring territory versus points for owning territory, or points for getting around monster obstacles versus killing monsters. You can add a quest system into a game or you can build a game entirely based on questing.

Quote:

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?


Yes, an object can have multiple script objects, and it or them can be used in multiple puzzles, and multiple objects/scripts can be used to solve a single puzzle.

Quote:

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.


I have rooms belonging to a level, and levels belonging to a dungeon. And dungeon level is a point multiplier. Exploration == questing.

Quote:

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


Not sure I follow. I would probably create a scent object and drop in the room. Discovering scent objects would then score you points. That is if I had tracking and wanted it scored. I don't, but that doesn't stop a builder from creating tracks/scents to be found and followed as part of a 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: Wed Apr 05, 2006 4:37 pm    Post subject: Reply with quote

Tyche wrote:
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.


I understand about debugging, but not the latter. That's one if the questions I posed. Why a list of quests? And need players be informed that n quests exists named X, Y, Z, etc.? I'm thinking not.

I didn't mean for players to look at, I meant for you to look at, so you could see who had done your quests.

Tyche wrote:
Quote:

The one-to-one mapping between "accomplishment bits" and objects seems strained; this is the cause of your dithering over the concept of "use".


The nature of the game changes if you reward points for robbing/killing a player versus points for meeting a player, or points for exploring territory versus points for owning territory, or points for getting around monster obstacles versus killing monsters. You can add a quest system into a game or you can build a game entirely based on questing.

<snip>

Yes, an object can have multiple script objects, and it or them can be used in multiple puzzles, and multiple objects/scripts can be used to solve a single puzzle.


Right, but say that one object with one script can produce different outcomes depending on the circumstances. For instance, I speak to a paladin who either (1) sees that I am evil and curses me or (2) sees that I am good and tells me a secret. These are two different results, which should be marked down in distinct ways for later use. But there's one paladin with one script. So the "one script = one accomplishment bit" idea breaks down here. This is a reason for the quest bits not to map 1-to-1 to scripts / rooms / objects.

That's not to say that accomplishment bits shouldn't also be assigned to all rooms etc., but I think that quests, which might be conceptually independent objects, should have their own bits not tied to other things. The meaning of the quest bit is "bob has accomplished this result, whatever it may be".

I agree that the players shouldn't see a central list of quests, or even a list of which quests they have completed. Where's the romance in that? They can already (in my mud, at least) see numerical stats describing their characters, no need to break the illusion any further.

I found that it was still useful to give them some notice, including a name, when they were doing a quest. This again comes back to debugging: ocasionally the quests get screwed up, and it's awfully useful if the player can say "I tried the 'oblong badger' quest but when I put the badger in the compression chamber it just disappeared!" rather than "I put the badger in the box and ..." because I have tools which will tell me about the quest if I know the name, but not if I don't.

Tyche wrote:
Quote:

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.


I have rooms belonging to a level, and levels belonging to a dungeon. And dungeon level is a point multiplier. Exploration == questing.


I can see your point. I decided that exploration was a fundamental enough thing that I should treat it as separate from questing, just like I treat killing monsters as separate from questing, although the quest engine is cognizant of where people have explored and what they have killed.

It seems like you have some different flavors of accomplishment bits here. The bit attached to a room isn't an arbitrary quest bit associated with the room, it's "have you visited this room?". So some of your bits are flavored, but some of them (the ones attached to scripts) are unflavored, by which I mean they might mean anything and don't have some generic meaning like "has this script executed?" or "has this script executed and returned true?". I am just making the flavored bits not be quest bits, but be various something elses, and only the unflavored bits did I refer to as quests.
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 Previous  1, 2
Page 2 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