Member Discussions

I am wanting to start a roleplaying medieval/fantasy themed mud and I would like it to be a good one and not a "run for 3 month and close failure". I have been working on the areas I would like to see the mud open with and have already produced the first 50 areas. I will also be using SMAUG code.

What I am looking for is anyone who would like to be part of this project to help brainstorm any future implementations into the MUD and overall ideas for it, or just anyone who wishes to just send me a simple/complex feature that they like to see in a mud.

I figure if it has a well balanced list of features that many players like to see in a mud, it will help with the overall success of this whole thing.

You can either post the feature(s) you like the most on this thread or email it to me at rhyeinbuilder@hotmail.com

I appreciate any help in advance, and hope to hear your comments soon.

Well, what ideas do you already want implemented? Do you have your heart set on any as things stand now? All that I know now is that it's stock and aimed at being medieval/fantasy, which is what I believe was in mind when that stock was designed. And roleplay doesn't have too much to do with code, generally. If it does then you have a large project on your hands.

In any case, I guess I'm just saying that if you put some things out there that you are already thinking about putting in... and/or give us an idea of what you're really aiming for, what ideas you have, etc... it would be easier for everyone to then comment on what you said and add on with other ideas and functions. That's just my personal guess though. For example, I can say that questing is a good idea rather than having pure hack/slash... but I would assume that would be rather intuitive. I can also say that a hand-coded questing system would be better than the stock one... but once again, I would assume that's rather well accepted. *shrug*

Best of luck in any case,
-Jess

Well, I know that I want to have an advanced questing system so that if nobody is around to roleplay with, they can go about some quests on their own, but their will also be many group quests, as I have some areas that grouping is encouraged and have a few dozen area quests inside the areas that will take a small group to finish the quest.

And I also do not want it to be pure hack/slash because I really don't like h&s all that much, especially it being the only method in the game to gain experience. I want to have a nice crafting system that will be enjoyable(that will not be botted) and able to gain experience through it as well.

Also, I want to have many trades in the game as well, such as mining, woodworking, fletching, leatherworking, merchant, weapon/armour/staff/wand/scroll appraising and things in that nature. Because, I've always loved those things and know many others like them as well, this too will also make another possible way to gain experience.

As well, even though I don't think I will follow any particular D&D campaign too closely on this, I would like to follow some of the ruleset of the 3rd edition with it's magic system and feats. I will probably also have a guild system and only have the starting classes of warrior, wizard, rogue, cleric and then join whatever guild you wish, as in ranger, mage, druid...etc.

I have a lot of other things I wish to see in this mud, though I am pressed for time right now and will add some more later after my daughter goes to bed.

Well, implementing the ideas is a lot harder than actually coming up with them. There have been discussions for immense ecosystems and that sort of thing on MUD discussion forums all the time, but not many MUDs actually attempt it and few if any do it to the extent originally proposed.

So easier said than done. On the other hand, there's still some things that I haven't seen done well in theory or in practice, so it certainly doesn't hurt to dream.

Anyways, one thing I'd like to see is a competitive market. Player should be able to create shops, buy land, form cartels, protect trade routes, found cities, etc. I don't want to just go into the forest and chop wood; I'd like to start a logging empire. And get into trade wars with my competitors, violent or not. Okay, not everyone can be a logging baron, but there should be interesting things at all levels of industry.

I mentioned in a thread a while back that I'm interested in a pioneer or gold-rush themed MUD, not necessarily role-playing. I also said that it didn't necessarily have to be a historical sort of discovery age -- it could just as easily take place in a fantasy world. Trying to build a town in an untamed land full of hostile mythical creatures, dangerous magical storms, foreign competitors, far away from the "old world", and being completely outnumbered. And also potentially very profitable.

Multi part quest:-

Orc Raiding Parties
Orc ships land at the docks, raiding the town every 2 - 3 days, killing everything in sight. If the ocs are successful in raiding the bank, players lose gold, etc. If the players happen to capture the orc captain alive, they will then be able to find out where the orcs come from.

Revenge!
Players can then set off to find the orcs and get rid of all of them once and for all. Once they kill the orc king, they will find an unsigned Letter of Marque from an "reputed" ally of your nation, financing the raiding expeditions.

Betrayal
Why does your staunch ally want to de-stabilise your nation? Who wrote the Letter - does it come from the King himself or a rogue baron/duke? Will the players let the King of their nation know about the Letter or will they investigate themselves?

This is where the real roleplaying begins, and I am sure you can take this anywhere you want it to.

Hope this helps.

Okay, a few things.

First of all, you have to know that everything is going to be botted that offers some kind of bonus for botting it, I would have to believe the key is to finding a medium which doesn't allow such a bonus. As such, you're starting to get into specific design elements, which are much much more important than the concepts behind the design, in my personal oppinion.

As for the feats and such, I would imagine there is a codebase out there that pretty closely resembles what it is that you're aiming for in terms of that, and if not, there certainly are ones out there that can easily be tailored to your intent. As well, I've heard of a few codebases that have crafting already implemented (though I'm not sure how good their systems are). I would guess your starting point would be a codebase like that, upon which you could add the other features.

Personally, the things I've seen already implemented in other MUDs that I've liked the most were quest/activity oriented, and non-repeatable. For example, (sorry KaVir), but I absolutely detest the Godwars questing system, as you simply repeat specific quests over and over again forever. I do, however, like Materia Magica's questing and mark system, by which you can quest hand-coded tasks which are done (more or less) one time alone, and which involve multiple parts. Their mark system is sort of a mini-quest thing, by which you get rewards like a normal quest for performing a feat which is hinted at during the course of the game, but not explicitly laid out. (ie, someone says to you that they need an egg from a pheonix, so you have to go and find a phoenix egg, and carry it back to him without breaking it... but note noone ever tells you where it is, and whatnot).

Anyway, best of luck regardless,
-Jess

(Comment added by mann_jess on Mon Sep 25 13:48:37 2006)

As well, I have to say that in my mind the important elements of the game are the realism, diversity, and immersion... where all three really feed into one another. Which features get implemented, so long as the ones that do adequately fulfill those elements, isn't really all that important to me.

*shrug*

Best of Luck, as always,
-Jess

> Personally, the things I've seen already implemented in
> other MUDs that I've liked the most were quest/activity
> oriented, and non-repeatable.

So do I (I'm using this approach as well), however the drawback is that it requires a lot more work, and players will complete the quests far faster than you can create them. You can spend hours creating a new quest, yet the players will complete it in minutes and then go back to their boring repeatable activities.

> For example, (sorry KaVir), but I absolutely detest the
> Godwars questing system, as you simply repeat specific
> quests over and over again forever.

Collect four items from around the mud, randomly selected from a list of 150 different items. Yes, it's pretty boring in the long run - but so are all repeatable activities. Yet back when it was added, it provided a welcome break from grinding mobs.

It's almost never viable to have no repeatable activities in a mud, and as a result those activities are going to get boring. But if you're going to have repetitive activities anyway, you might as well give the players a selection to choose from, so that they can vary their gameplay a bit (and pick the least boring approach).

The real problem with the item collecting in GodWars wasn't so much that it was repetitive, but rather that it was repetitive and necessary. Killing thousands of mobs got boring, and so did questing - but you had to do excessive amounts of both in order to create a decent character.

My mud is taking a similar approach to others, as I don't really see a way to make non-repetitive quests, unless you have a group of people who do nothing but make quests on a daily or weekly basis.

However we are also adding in functionality so that we can make quests up on the fly, as it were. This entails things like:

Monster(s)
Item(s)
Awarded XP
Awarded $$
One time only?
Enable/Disable

These quests are able to be "turned on/off". When off, if they try to go through the quest, they get no xp, $$, etc.
If they can only be done once, it is noted in their character file that quest# <X> has been completed. Therefore they cannot go through it again.

Another thing we're doing is not only multiple part quests, but also where they cannot do certain parts of it til they become higher level. (ie: the item they seek is in an area that is level restricted).

As to the repetitiveness itself, eventually anything you will add in will become repetitive, no matter what it is, quests, monsters, raids, etc. All you can do is keep the world growing, adding new things, changing things around, etc. Remove old quests (or mothball them for a while), and substitute new ones.

As to XP earning, there is few ways other than killing monsters or doing quests that can be done for xp. Sure, you can give it for crafting, but people will bot, gain enormous amounts of xp for doing nothing. Awarding XP for RP is fine too, but its subjective, and often not fair. (if someone is a great RPer, and the immortal online just doesn't like that person, they'll just award a minimum amount, but to someone they like, they will often give more.)

One suggestion you might use to gain your eventual players to get more interested, and at the same time add more to your game, give xp to those who suggest things for implementation that actually go into the game. example: If a player suggests a new spell, and you add it, award them an amount, like 1000 x spell level. If they suggest a new command or feature, even more, perhaps. This way your mud grows, they feel involved and more proud of the mud, plus fosters good will towards the game if players know that you listen to their ideas and they might get implemented.

>My mud is taking a similar approach to others,
>as I don't really see a way to make non-repetitive
>quests, unless you have a group of people who do
>nothing but make quests on a daily or weekly basis.

Good point, does anyone know of a mud where the players make quests that have xp/coin/item rewards?

Maybe there could be a system, like a crafting system, where the player-characters could make the quests.

Well... when I mentioned that in my post I was actually thinking of precisely what kingarther said. Creating a quest doesn't have to take hours, in fact if you create your system well enough (starting with some of the specifications kingarther pointed out, for example), creating a quest can take only a few minutes. Simply define a few types of quests that can exist, add in some slots for tasks which need to be accomplished in the quest, a string for the name, and a string for the description, and a builder can simply input everything as quickly as he could create anything else like a room or mob, for exmaple. In that regard, you or another builder can spend... let's say... an hour a week (which is almost no effort) creating quests for a specific level range, and in about 10 weeks, or three months, you'll have enough quests to keep your players occupied for quite a while with hundreds upon hundreds of unique quests appropriate to their level.

Of course, eventually players will have exhausted somewhere around all the quests you created, however that will naturally be at your MAX level when that happens, and by that time, you can easily create other tasks and activities for a player of that level to do. Inevitably players that have maxed out their level will run out of *unique* activities... but that is unavoidable. In my mind, a questing system that keeps every *other* player occupied with unique activities is pretty good.

Materia Magica was on my mind as my example of this, and I only bring it up again because it answers the previous poster's question of a MUD which allows players to create quests as well. Materia Magica is a pay-for-perks MUD, however (in my oppionion) unlike other pay-for-perks muds it gives out quite a bit of reward-units for in-game activities which benefit the MUD. Quests are one of these things, as any player can submit a quest (Description, tasks, level ranges, etc) for reward-units. As well there are weekly newspapers, as I recall, that you can write for to get RUs consistantly, as well as newbie guides and more.

In my oppionion, this is a wonderful way to get players involved in the creation of the game, while being rewarded in the process. If you don't have reward-units or credits, give out experience or gold, or something else tangible as a reward to players that help out. In this manner, you don't have to worry about giving responsabilities to deadbeat or abusive imms, you don't have to worry about your players getting too bored (as they can submit ideas to improve the game if they *are* bored), and you have happy, productive players. Most helpful activities like this can even be RPed if desired... such as founding a town in the wilderness, being a journalist for a newspaper, or recruiting candidates to help with a specific questing mission. *shrug*

In any case, best of luck to everyone,
-Jess

(Comment added by mann_jess on Mon Sep 25 21:53:34 2006)

*Kingarthyr*, I apologize. I knew there was something else to that name that I was missing, but I was too lazy/forgot to check.

My apologies,
-Jess

(Comment added by mann_jess on Tue Sep 26 1:17:50 2006)

Alright, that whole misspelling of opinion thing is pretty embarrassing.... ... you can all just forget that. My spelling is bad, but I really don't know what possessed me that time.

(Comment added by mann_jess on Tue Sep 26 1:19:46 2006)

Pfft... and I didn't even get to the other spelling mistakes before I made that edit..... *sigh* *sulk* Alright, so my idiocy has shown through... oh well, now you all know it. No more hiding!
-Jess

I appreciate all the advice, thoughts, and comments from all of you and just wanted to say thank you. And keep up the good discussion about what things you like in muds you have played.

It's giving me a good understand, at least with quests systems, what worked and didn't work for other muds.

> Creating a quest doesn't have to take hours, in fact if
> you create your system well enough (starting with some of
> the specifications kingarther pointed out, for example),
> creating a quest can take only a few minutes.

The sort of quests you can produce in minutes are the same quality of quests you can generate automatically. If that's the extent of your quest system, it starts raising the question of whether or not it's even worth hand-writing them. Either way, you'll end up with precisely the sort of repetitive quests that you've said you detest; producing unique in-depth quests takes time.

No, not entirely. For example, let's say we define our questing structure or whatnot as something like this... (don't mind that it's pseudocode). (class=struct, String=char[])


class quest
{
String name;
String description;
Task[6] tasks;
int min_level;
int max_level;
int time_to_complete;
}

class task
{
String description;
int requirementType;
int vnum;
}

int REQUIREMENT_KILL_A_MOB = 1;
int REQUIREMENT_RESCUE_A_MOB = 2;
int REQUIREMENT_ARREST_A_MOB = 3;
int REQUIREMENT_RETRIEVE_AN_ITEM = 4;
int REQUIREMENT_DESTROY_AN_ITEM = 5;
int REQUIREMENT_EAT_AN_ITEM = 6;
int REQUIREMENT_ENTER_A_ROOM = 7;


Now that's a pretty basic setup, lacking some obvious requirements that could be implemented, and lacking some extra elements to the quest structure, as well as some other peices. Now, a builder, within a few minutes, can fill in those attributes creating, perhaps, a quest like:

The Evil Wizard of Snot
An evil wizard has taken up residence in our beloved town of Haven with the sole purpose of stealing the snot from every last one of our residents! He must be stopped at all costs, for as the Mayor of this town, I simply cannot live without a stuffy nose! It is rumored that he has hired mercenary bodyguards to protect a fabled relic from which he derives his power. You must find this wizard and arrest him, disposing of his mercenary bodyguards in the process. Afterwords, you must find the relic and destroy it to ensure that no other fiend will take his place after his demise. Bring the wizard back to me along with the swords of his mercenaries as proof of their death, and you will be greatly rewarded!
Task[0] = REQUIREMENT_ENTER_ROOM, vnum 1000 ("The snot wizard's chambers")
Task[1] = REQUIREMENT_ARREST_MOB, vnum 523 (The wizard. Must fight and incapacitate him to arrest him)
Task[2] = REQUIREMENT_KILL_MOB, vnum 121 (One bodyguard)
Task[3] = REQUIREMENT_KILL_MOB, vnum 121 (Other bodyguard)
Task[4] = REQUIREMENT_RETRIEVE_ITEM, vnum 523 (A sword)
Task[5] = REQUIREMENT_RETRIEVE_ITEM, vnum 523 (A sword)
Task[6] = REQUIREMENT_DESTROY_ITEM, vnum 2391 (The relic)

Now that, despite being a pretty rediculous quest, is something that can't be generated automatically. It involves not only a multi-part quest which is coherant and has a flow, but also has a specific reason to exist... If you attempt coherency and reason in automating quests, you get things like: "The pope has stolen from our treasury, he must be killed!"... not to mention coherant *multi-part* quests are literally impossible. And for that quest, what does the builder need to do? Come up with the idea, write the name/description (the majority of the time), find the vnums of all the objects/mobs involved, and input them. Done.

Miniquests, or extended-quests, or whatever you want to call them could also be added, which would be more in-depth quests which were not given to you by simply typing "quest request" or whatnot, but were rather hinted at during the course of the game. Those would take more time to create, but also could not simply be cycled through like normal quests given that you'd have to first be aware they even existed to be able to accomplish them.

With a combination of the two, I think you can quite easily create a MUD that has the diversity/immersion alot of other posters seem to be so interested in, with very limited amount of effort... especially if, as previously mentioned, your players help out with some of the work.

*shrug* Best of Luck,
-Jess

> For example, let's say we define our questing structure or
> whatnot as something like this...

[snip]

Yeah that's pretty standard for this sort of design, and it supports automated quests as easily as it does hand-written ones. The time-consuming part is all the additional content and infrastructure that a unique and interesting quest requires - specialised mobs, items, rooms, scripts, etc. Without those, each new quest becomes a rehash of previous quests.

> If you attempt coherency and reason in automating quests,
> you get things like: "The pope has stolen from our treasury,
> he must be killed!"...

Only if you do a really poor job of designing it.

> not to mention coherant *multi-part* quests are literally
> impossible.

No, they're perfectly possible. The problem is that, because they don't have the specialised content, they end up becoming repetitive. It becomes a case of "Oh no, not another evil wizard..."

Just about any type of quest will become repetitive. No matter how many "new" or extended quests are added in. This is for the simple fact that players will often have multiple characters, they will constantly be re-doing the quests for their other characters. Since few truly new people influx on mudding in general, we basically see the same faces on every mud (in one way or another). And there are a finite number of quest types that can be done on a mud. These usually will involve: trades, rescues, defeating a foe, or retrieval of an object/item. I believe every quest ends up in one of those types. Those that combine two or more of the types will also become repetitive.

As someone said, people will eventually say, "oh, I have to defeat another <insert alignment> <insert monster type>." Or "oh, I have to rescue another ..." etc.
This also holds true for pretty much everything else on a mud, PnP game, graphic game, etc.

As admins, builders, coders, whatever, all we can do is continue to add, mix up, remove quests, etc to SEEM like something new is there for something to do. Its no different than someone buying a game like GTA, or WoW, or whatever. After a while, the "newness" wears off, or they've done everything a multitude of times and they get bored. By opening new areas, "new" quests, changing what invades/raids what area, etc we mix things up sufficiently to hold the players' attentions

What my mud has been working on while we code the new codebase is to make it easier to implement these things with the least amount of code changing so it can be done on the fly (I don't mean changing the original code, as this is a completely new codebase, but by trying to code all the possibilities in, and having interfaces to create the things on line, on the fly so we can mix & match stuff). So far, we've succeeded in all we've been working on, making the systems both easy to learn, immensely versatile, and very powerful. Lucky for me, I have a coder who knows what he's doing really well, has also been a PnP DM for years, is a touch devious, and can convert my design ideas into code, while adding in his own ideas we discuss, many of which I hadn't thought about because I didn't know how to word it, so I gave him as much info as I could and we discussed it til we came up with what I had intended, but usually even better because he helped flesh it out.

One of the ideas we've been playing with is the crafting system (and other skills in general) to have training points assigned each time someone levels up. The player assigns the points however he wants in the skills he has, and thus trains them so he succeeds more often with that skill, thus more or less personalizing his character more than many muds I've seen.

Oh, about the players contributing to the mud...one of the things we've done is added a skill for wizard-types called "research spell", what it does is create a mudmail to myself and my coder with a specific set up. (ie: spell name, type, spell description, damage/healing effects, etc).

I doubt it'd be difficult to use something similar for general players, perhaps a command like "submit_idea" or something along those lines.

The point is that there is a major difference between telling someone what they have to do and telling them why they have to do it. An automated design cannot create a *reason* for you performing the quest like my example. If you allow your automated system to give out a message that the mob in question has stolen the snot from the inhabitants of the town, then someone other than the mob named the "snot wizard" will eventually have a quest that says he did it. As well, it will naturally happen multiple times and will no longer be unique to one quest. As well, you cannot create *coherancy* like my example, as there is no way to tell, in an automated form, what mobs are thematically tied to one another and in what way. The mercenaries that hang around near the snot wizard are, in the eyes of your code, exactly the same as the mercenaries that hang around in the local tavern... but thematically they are much different. The problem is that if you create the mobs/items for the quest when the quest is requested, you get the same mobs and items every time. If you choose random mobs/items, you have absolutely no coherancy. However if you allow your builder to define all these things, you get both.

My ultimate point is that there is a major difference between:
An evil wizard has taken up residence in our town and must be killed! His name is <choose_random_mob_with_mage_class_in_town_between_level_range>, but his location is unknown. You have X minutes.
Which would naturally occur multiple times for every level range, with only the mob hypothetically changing... and:

A legendary mercenary psionic, is seems, has been hired by someone to take over the town, and kill me in the process! His name is Hajeezamafut and his reputation for his evil deads and startling accuracy is widespread. Ironically, he used to be my best friend in high-school, but it seems he has now been bought out to take my town from me! *sob* I knew he never really liked me, and was only using me to get my lunch money! You must find him and do this task and this task and this one... oh and this one too!
Personally, I would much prefer doing the second one, especially when enough quests have been created in my level range so that I won't ever have to repeat that quest with this character.

Now, of course creating a second character is going to expose you to the same quests again... however our hope is that
* one: There will be enough quests in a given level range that the first couple times around you will not have experienced every single one, so that there isn't a long chain of repetition...
* two: There are enough level ranges that by the time you max your level (or get to whatever level you do) and create a second character, the lower level quests which you will now be performing won't have been done by you recently. By the time you finish those, the higher ones won't have been done recently... so there's not immediate repetition... and...
* three: you're playing a second character, so hopefully you enjoyed it the *first time around* enough to do it again.

Ultimately, yes, by doing our quests this way we will still be creating a system that conforms to set archetypes, however the point is that this system is *Better* than stock/automated systems, is very easy to implement and for a builder to create, and can be very interesting the first couple times through, rather than being repetative pretty much as soon as you begin. When designing your game, you can never put too much emphasis on one element or feature, questing included... and if you do, it makes absolutely no difference how in-depth, immersive or well thought out that feature is, because it will become the only feature. If, however, you create quests like this that are unique to one another, create miniquests or extended-quests which are much more in-depth and are performed during the course of actual game-play, create an interesting combat system, a diverse economy which allows for professions including trading and crafting, and a number of other activities the character can take part in... you've just create a diverse and immersive world, which in no way resembles the mindless features stock has become notorious for.

In any case, Best of Luck,
-Jess

(Comment added by mann_jess on Tue Sep 26 13:32:19 2006)

And I believe kingarthyr also made the point pretty well regarding this questing system:
As admins, builders, coders, whatever, all we can do is continue to add, mix up, remove quests, etc to SEEM like something new is there for something to do. Its no different than someone buying a game like GTA, or WoW, or whatever. After a while, the "newness" wears off, or they've done everything a multitude of times and they get bored. By opening new areas, "new" quests, changing what invades/raids what area, etc we mix things up sufficiently to hold the players' attentions

The point is that doing quests this way allows you to change what quests the character can do... The best you can do with automated quests is to change the algorithm used, which doesn't in any way change the feel of the quests.

Best of Luck,
-Jess

(Comment added by mann_jess on Tue Sep 26 13:38:28 2006)

And as for the scripts and specialized mobs you refer to, that moreso fits into my definition of miniquests or extended-quests, which would essentially be multi-part, like we can make our normal questing system, however the tasks wouldn't be laid out right in front of you before you perform them... they would change and evolve as you got further into it, until it was completed. This, however, doesn't mean that these specialized mobs cannot also be used for questmaster quests, though. A mob is a representation of some person, who is capable of performing multiple tasks in his life... (i.e. perhaps the snot wizard was created for a miniquest or extended-quest which involved... I don't know, gathering spell components for the research of a new spell. He was aptly named because he lives in a mansion where snot covers the walls.)
-Jess

> The point is that there is a major difference between
> telling someone what they have to do and telling them
> why they have to do it. An automated design cannot
> create a *reason* for you performing the quest like
> my example.

It can, but that's not going to help - you don't make a quest unique and exciting just by slapping a pretty description on the front. After a few quests the players are just going to skim-read it and mentally break it down to "kill wizard".

To make the quest fun and exciting you need to add content for it, and that takes time and effort.

> If you allow your automated system to give out a message
> that the mob in question has stolen the snot from the
> inhabitants of the town, then someone other than the mob
> named the "snot wizard" will eventually have a quest that
> says he did it.

Only if your design is broken.

> As well, it will naturally happen multiple times and will
> no longer be unique to one quest.

You could address that by defining specific elements as one-shot (in this case the "snot wizard").

> As well, you cannot create *coherancy* like my example, as
> there is no way to tell, in an automated form, what mobs
> are thematically tied to one another and in what way.

I fail to see any reason why you couldn't automate that. Indeed it seems pretty obvious to me that you'd want to build such associations into the quest generator.

> The mercenaries that hang around near the snot wizard
> are, in the eyes of your code, exactly the same as the
> mercenaries that hang around in the local tavern...

Well I've not actually written the code, but if I did it would certainly keep track of such associations.

> The problem is that if you create the mobs/items for the
> quest when the quest is requested, you get the same mobs
> and items every time. If you choose random mobs/items,
> you have absolutely no coherancy. However if you allow
> your builder to define all these things, you get both.

And if you code it properly, you also get both. A generated quest doesn't mean picking any old random mobs and objects and throwing them into a bucket - the elements need to be selected and assembled based on specific criteria.

It's like a magic item generator. If you want your mobs to drop random magic items, you don't just make them drop anything possible - you base the item types and their materials on the mob dropping them, and then calculate the bonuses based on those factors.

If you have swarms of killer bees which drop steel gauntlets of kicking, then it's going to look pretty silly. But that's a problem with your design, not with the concept of randomly generated magic items.

The same rule applies to randomly generated quests.

> Now, of course creating a second character is going to
> expose you to the same quests again... however our hope
> is that
> * one: There will be enough quests in a given level range
> that the first couple times around you will not have
> experienced every single one, so that there isn't a long
> chain of repetition...
> * two: There are enough level ranges that by the time you
> max your level (or get to whatever level you do) and create
> a second character, the lower level quests which you will
> now be performing won't have been done by you recently. By
> the time you finish those, the higher ones won't have been
> done recently... so there's not immediate repetition...
> and...
> * three: you're playing a second character, so hopefully
> you enjoyed it the *first time around* enough to do it
> again.

One would also hope that the classes are sufficiently different that the same quests will require different strategies the next time around.

> Ultimately, yes, by doing our quests this way we will still
> be creating a system that conforms to set archetypes,
> however the point is that this system is *Better* than
> stock/automated systems, is very easy to implement and for
> a builder to create, and can be very interesting the first
> couple times through, rather than being repetative pretty
> much as soon as you begin.

I've not seen any evidence of your proposal being 'better' (although do I believe that hand-written quests can be considerably better, I do not believe that a quest thrown together in a few minutes, as you've proposed here, would be any better than a generated one).

A generated approach requires more work to set up initially, but once in place requires less work to expand.

Both approaches will become repetitive, unless you're prepared to put a lot of additional effort into them.

> When designing your game, you can never put too much
> emphasis on one element or feature, questing included...
> and if you do, it makes absolutely no difference how in-
> depth, immersive or well thought out that feature is,
> because it will become the only feature.

I can't say that I agree with that. In my opinion it's a good idea to have a central feature, a focus point around which the other aspects of the game revolve - something you concentrate on doing exceptionally well. It gives the mud direction, and makes it clear what sort of game one can expect.

What I dislike are those muds which have no real direction or focus, just a bit of this and a bit of that. A bit of combat, a bit of puzzle, a few minigames here and there, a bit of roleplaying, and so on. It feels like the creators had no real idea what they were doing, just tacking on bits and pieces. A jack-of-all-trades that does nothing particularly well.

*Growl* You drive me crazy KaVir!! Everytime I discuss something with you I feel like we disagree about someone I find so basic and intuitive I assumed noone would disagree. I'm sure you feel the same way about me. Bleh. At least you keep me busy with discussion though. *smile* Oh well. I'll convince you of something one of these days.

As far as the last part of your post with the jack-of-all-trades thing... I wasn't exactly suggesting that you only implement a part of one thing and a part of another. If that was done, I would entirely agree. Instead, I'm suggesting that you implement one thing well, then implement another thing well, and another thing well, and so on. However, I don't believe any MUD should be centrally focused on one element alone. There's no reason in my mind that a MUD cannot keep a multitude of players who all have different interests happily occupied.

As for the rest... okay, look at it this way. There is no possible way to programatically link two mobs thematically to eachother without builder input. You can find mobs that are near one another and assume they're linked, but let's say our snot wizard's lair is directly below or above some tavern... now the mercenaries in the bar are even closer to the wizard than the mercenaries which he actually hired sitting in the other room. You could pick out keywords from names or descriptions and assume they had relevance... but what happens when the builder is attempting to blend the mercenaries in (as it thematically makes sense since they're attempting to hide a relic). Nowhere in the description of the mercenaries is there going to be anything regarding the snot wizard, and nowhere in the snot wizard's description will it have anything about mercenaries. Or when a word appears in two descriptions for other reasons. The snotty-nosed brat in town is in no way linked to the wizard. You could assume that vnums close to one another are linked, but that poses very obvious problems, especially when somewhere along the line a table or washcloth becomes thematically linked to a king and you attempt to pawn it off as relevant. (Destroy the king's washcloth! That'll show him!)

Reason cannot be automatically created without builder input, unless there are standard reasons which are used over and over again which will become rather old. No piece of code ever designed can write like Shakespeare could, create poetry, write a novel. If you want each quest to have a unique premise, code CANNOT do that for you in any kind of decent way... and hey, if you can get your code to write beautiful poetry or an enthralling novel, what in the world are you doing working on a MUD anyway? At one point or another, someone is going to have to define what premises can be used, it is absolutely inevitable. Naturally, the more premises you have to choose from, the more diversity and unique-ness you have in the MUD. I can't think of any more premises you could possibly have than one for each and every quest given out... and if you create one premise for every one quest, there's absolutely no reason to automatically and randomly assign the premise to random tasks unless you want odd results and repetition. Each premise, therefore, is best off tied to, and ONLY to, a specific quest. Therefore, you have my approach.

you don't make a quest unique and exciting just by slapping a pretty description on the front. After a few quests the players are just going to skim-read it and mentally break it down to "kill wizard".
Of course some players will... but some players will actually read the descriptions too. With that theory, there's no point is designing rooms with names and descriptions, because after a few directional commands players are just going to break it down to "exits: north, south". There's also no point in comming up with a storyline, because players are just going to skip that too to get to partaking in the game. In fact, let's just remove all the descriptions, realism and immersion for everything everywhere in the game. What are we left with? A shell in which you can use commands. Yes, that sounds like a blast.

> If you allow your automated system to give out a message
> that the mob in question has stolen the snot from the
> inhabitants of the town, then someone other than the mob
> named the "snot wizard" will eventually have a quest that
> says he did it.

Only if your design is broken.
Yes, precisely, and an automated design that allows for premises to be tied to tasks in a way that does NOT involve a builder manually doing it at one point or another is broken for that very reason. There are two options here, one is that you have a snot wizard, but have no premise that the snot wizard has been stealing snot from the town. In that case, you've just limited the number of premises you can have in your quests, AND you've removed EVERY unique-to-one-scenario premise from your game. Two, you allow for the snot wizard stealing snot from the town premise, in which case in an automated system, that premise will be assigned to random mobs and/or random tasks, which is completely incoherant and rediculous. A beggar stealing snot from the town using a cup from the bar which you must destroy, along with killing his henchmen, a priest of the temple and a mangy dog, is quite obviously broken. Of course, you can add alignment stipulations and a few other requirements, but you will still get random results because it is the innate nature of automating it! You cannot automate it without random results!

> As well, it will naturally happen multiple times and will
> no longer be unique to one quest.

You could address that by defining specific elements as one-shot (in this case the "snot wizard").
Yes, and who would define this? Who would come up with the concept of the quest for the snot wizard and define it as being a one-time-one-mob-only-quest? A builder, using my specifications! The code wouldn't figure out that this quest is very specific and define it as that, a person would have to!

Automating quests naturally requires that the premises you use be adaptable to the tasks, mobs and items randomly selected. Naturally, there are only so many of these premises that can be created... Someone has stolen something from someone important -> evil aligned mob. Someone has killed someone important -> evil aligned mob. Someone has done something disgracefull or broken a law -> evil or chaotic aligned mob. Something has been lost -> important item. I can think of a few more... but even those, if used in an automated form (and even considering how few there are that even fit this category in the first place), cannot contain a unique description of the events that transpired. Nomatter how many items are stolen from the treasury which need to be recovered, you're still going to get the same few basic descriptions which are programatically hard-coded to be given out, of how it was stolen and/or what type of person did it. Allowing builders to add and specify information about those quests allows a greater amount of diversity than hard-coding a certain amount of information. I don't see how that can be argued against.

And as for the quests require other specialized things and time and whatnot... I agree that some do, and I have been, this whole time, encouraging the addition of those as well... however with quests that require a great length of time, there is a major problem of: The players can complete your quests much faster than you can make them! As a result, if you want a questing system that has the ability to keep players occupied, you have to have this questing system as well. The only other options are either to sacrifice coherancy and reason, or to not have a questing system that keeps players occupied.

Best of Luck,
-Jess

> As far as the last part of your post with the jack-of-all-
> trades thing... I wasn't exactly suggesting that you only
> implement a part of one thing and a part of another. If
> that was done, I would entirely agree. Instead, I'm
> suggesting that you implement one thing well, then implement
> another thing well, and another thing well, and so on.

But you'll end up with a mud that doesn't excel at anything - that's what I'd consider a "jack-of-all-trades" mud.

> However, I don't believe any MUD should be centrally
> focused on one element alone. There's no reason in my mind
> that a MUD cannot keep a multitude of players who all have
> different interests happily occupied.

Okay, consider the scenario: Four mud developers each create their own mud.

Mud 1: The mud owner focuses on combat, pouring a huge amount of time and effort into creating the deepest and most intricate combat system he can come up with. The other features are then designed around that - a competitive clan system, PK events, coordinate-based movement (to better faciliate ranged weapons), a magic system specifically designed to integrate seemlessly with combat, quests revolving around challenging fights, mini-games designed to test or enhance combat abilities, and so on.

Mud 2: The mud owner focuses on exploration and puzzles, utilising them for all aspects of the game. The world is full of mazes and hidden rooms, many mobs ask riddles and can only be defeated by learning their secrets. The combat system is turn-based, with different weapons drawing parallels to different board games. The magic system allows players to generate spells and potions through experimentation and problem-solving. Various mini-games are also available, each based on a different type of puzzles.

Mud 3: The mud owner focuses on roleplaying, creating a huge amount of background story and developing features geared towards improving the roleplaying environment. The world is laid out in a logical way, with lovingly hand-crafted descriptions. In-depth support for player-controlled organisations is provided, allowing players to create networks of IC contacts, OOC friends they enjoy roleplaying with, etc. Combat has different modes, allowing the players to settle disputes through either roleplaying or code, with the latter using an emote parsing system to generate the results based on the way the characters act. Numerous smaller features would also be included, each designed to add to the flavour and immersion of the gaming environment.

Mud 4: Following your proposal, the mud owner works on the combat system for a bit, until he thinks it's good enough to do the job. Then he does the same for magic, movement, quests, and so on.

Bubba loves combat, Boffo adores puzzles and Buffy is a fanatical roleplayer. Which mud do you think each of them is going to play? Perhaps they'll play your mud if their favourite is down, but you're always going to be the backup choice. Except of course, that implies that you're running the only mud 4, when in fact most muds fall into that category.

> As for the rest... okay, look at it this way. There is no
> possible way to programatically link two mobs thematically
> to each other without builder input.

You link them when you're defining the rules for the automated quest generation.

> Reason cannot be automatically created without builder
> input, unless there are standard reasons which are used
> over and over again which will become rather old.

They certainly can be generated - it's no different than, say, generating a description.

> No piece of code ever designed can write like Shakespeare
> could, create poetry, write a novel.

Code has already written poetry and novels. And while it might not be of a high standard (yet), it's far more complex than generating the sort of descriptions we're talking about here. Quest descriptions don't need to be generated from scratch - you can assemble them from a mixture of fixed sentences and dynamic tags, producing something of a pretty decent quality without too much effort. I use the same approach to generate player descriptions, and I consider the results perfectly sufficient.

> > you don't make a quest unique and exciting just by
> > slapping a pretty description on the front. After a
> > few quests the players are just going to skim-read
> > it and mentally break it down to "kill wizard".
>
> Of course some players will... but some players will
> actually read the descriptions too. With that theory,
> there's no point is designing rooms with names and
> descriptions, because after a few directional commands
> players are just going to break it down to "exits: north,
> south".

You're missing the point. What I'm saying is that the description is irrelevent to the purpose of quests, because quests are intended to provide activities.

Room descriptions provide immersion and greatly improve the feel of the game. But they are not an "activity" or "challenge" in their own right. Perhaps some people enjoy reading them, but if your mud contained no features other than the ability to walk around reading room descriptions, I doubt many people would hang around.

The same is true with quests. You can give them a description to add to the immersion, perhaps explain some of the background story behind them - but that won't make them fun or exciting. In order to make the quests an enjoyable activity you need content.

> > You could address that by defining specific elements as
> > one-shot (in this case the "snot wizard").
>
> Yes, and who would define this? Who would come up with the
> concept of the quest for the snot wizard and define it as
> being a one-time-one-mob-only-quest? A builder, using my
> specifications! The code wouldn't figure out that this
> quest is very specific and define it as that, a person
> would have to!

I think you misunderstand what an automated quest system involves. It's not some gibbering coder in a dark room shouting "Go, tiger!" and letting the computer do everything - someone has to define the rules and conditions of the system. A human has to specify that certain mobs can be used in certain quests, and define their relationship to other elements. Only then can the quest be generated, and it will do so based on the criteria it's been given.

> with quests that require a great length of time, there is
> a major problem of: The players can complete your quests
> much faster than you can make them!

Indeed, as I said in my first post.

> As a result, if you want a questing system that has the
> ability to keep players occupied, you have to have this
> questing system as well. The only other options are either
> to sacrifice coherancy and reason, or to not have a questing
> system that keeps players occupied.

...or use automatically generated quests.

I just have a quick point to make:

Consider Diku combat as an analogue to any type of autoquest. It has a library of descriptions (hit messages), and different options (skills) to advance the quest (killing your opponent). With this analogy normal autoquesting would be like using diku combat code against a post that does not fight back. Eventually you just see the same messages over and over again, and the outcome is always the same. Now advance the concept by throwing in a simple mob AI that fights back and you have increased the playability somewhat but in the end you begin to see similarities in the way the algorithm fights back. So advance the concept further to allow PvP combat and you now have to pit your wits against someone just as unpredictable as you are.

Moral of the story: Multiplayer autoquests that have mutually exclusive outcomes.

Okay, sir KaVir... this is once again getting into definitions of what we're arguing about, because we never seem to have the same definitions. You are now arguing against me using my points. There are two kinds of quests you can create.

One, automatically generated quests, which are like the stock ROM quests. There is a fabled book, a crown, and a staff as quest objects. When the player requests a quest, one of two kinds of quests is chosen: Retrieve one of those quest objects which is thrown randomly into the world, or kill a mob which is randomly chosen from anywhere in the world. Either way, some stock message is sent to the player saying "The item was stolen" or "The mob broke the law". This message is randomly selected, however in the stock version there are only about 1-2 for each situation.

Two, hand-built quests, which are like Materia Magica's quest system, and like mine (though noone but me would know that since my MUD isn't open.) A builder at one point or another builds a quest, which is then assigned some number, and placed into some database or file somewhere. When a player requests a quest, the database or file is searched and a random quest is chosen. The specifications the builder supplied for the quest are given to the player exactly as supplied, exactly the same way, every time.

Now each of those two can obviously be expanded upon... An automated system can, of course, create a ton of messages to be sent regarding what happened to the item, or what the mob did... the mob's alignment can be checked against certain specifications... multiple tasks can be added instead of just one... whatever. Likewise, the hand-built quests can contain multiple tasks, can have level ranges and other requirements, can only be done a certain number of times, etc. But the distinguishing factor, nomatter how everything is done, is that an automated quest system randomly pairs one thing with another. Description with task, mob with item, whatever... it's all randomly paired. Perhaps there's even certain criteria performed before everythig is paired... perhaps even a selection process... but it doesn't matter, it's still essentially random. A hand-built quest will never be random, and in fact the overall quest, in and of itself, is going to be generally the same every time. There may be slight discrepencies if the questing system is designed that way... (i.e. perhaps a builder can assign a chance that one mob will be the target, and a chance another mob will be instead)... but the end result is that the quest is selected from some DB somewhere, and the specifications are followed specific to that quest.

As a result, it makes absolutely no difference whether the quests are hard-coded into the game or created with an OLC, an off-line builder, whatever... If the MUD creates it by patching things together, it is automated. If a builder creates specifications for that quest, and then that quest is selected... it is hand-built. I'm not going to repeat myself too much for from my other posts again... however if you randomly patch things together, the result is one of two things: 1) You have carefully selected which things will be patched together, so there is a limited number of choices, and each one will fit reasonably with all the others. This drastically limits the number of kinds of quests you can have, however, and as a result quests are repeated over and over again. "Vile pilferers have stolen the royal crown from the treasury. You must find it and bring it back! It was last seen ____!" Yes, this is realistic, but what are you sacrificing for it to be realistic? 2) You have created a number of things to be patched together with more regard to getting unique quests than to having realistic ones... This, quite obviously, creates unrealistic quests like a beggar stealing the snot from the inhabitants of the town with the aid of his magical beer bottle and two companions, the priest and the mangy dog. Yes, this is a unique quest... but what are you sacrificing for it to be unique?

Hand-crafted quests, however, will always be unique (given that there's only one of them), and will always be realistic (given that a builder has personally overseen their creation). With specifications like:
Enter the name of the quest:
Enter the description of the quest:
Enter the type of the first task (type help to see different types):
Enter the vnum of the mob the first task will be for:
Enter the type of the second task or type enter to skip this task:
...
Enter the vnum of the object the sixth task will be for:
Quest created!
...etc. Builders can thus create a quest in a matter of minutes which will be unique and realistic. With that in mind, they should be able to create so many of them that each quest will hardly ever be repeated. (Especially if players can get rewarded for submitting quests as well).

Anyway, I don't believe there's really any better way for me to explain it, so if you disagree, then you disagree... Keep in mind, as well, I'm all for automatically generating content. 98% of my world is automatically generated, from exits to room names to descriptions. And yes, I am quite happy with how they all turned out... but descriptions of rooms, mobs and players don't in any way require logical reason for an action, nor do they entail completing tasks. These are things that simply cannot be adequately automated.

As for the inital part about the jack-of-all-trades thing, you are assuming that the person who doesn't center his MUD around one feature also has very low requirements for the quality of each feature, and/or puts little time into the development of each feature before moving on. That is not at all what I inteded. Fine, start out developing your MUD out as purely combat-oriented, but that's no reason that when you get combat adequately finished... (or I should say well finished)... you can't implement other features just as well. It doesn't have to be, "If you're on this MUD you MUST kill stuff. You *can* quest, and you *can* explore, but you MUST slaughter." That may be how alot of MUDs are now, but that is in no way an indication of how they can or will be.

Best of Luck,
-Jess

Hand-crafted quests, however, will always be unique (given that there's only one of them), and will always be realistic (given that a builder has personally overseen their creation). With specifications like:
Enter the name of the quest:
Enter the description of the quest:
Enter the type of the first task (type help to see different types):
Enter the vnum of the mob the first task will be for:
Enter the type of the second task or type enter to skip this task:
...
Enter the vnum of the object the sixth task will be for:
Quest created!
...etc. Builders can thus create a quest in a matter of minutes which will be unique and realistic. With that in mind, they should be able to create so many of them that each quest will hardly ever be repeated. (Especially if players can get rewarded for submitting quests as well).

These quests will be unique, but dull and unoriginal. It's like a generic action movie sequel plot: bad guy starts causing trouble, reluctant good guy comes out of retirement to go kick the bad guy's rear end, car chases happen, love interest gets kidnapped, etc. Next time, it's the exact same plot ... except in space.

So your "hand-written" templates are only a mild improvement over "the vile X has stole Y". The story changes, but the basic action is the same. After the 10th car chase, it gets kind of boring.

Oh look, this time I'm off to fetch hair tonic for the king, who suffers from the curse of male-pattern baldness that has been passed down for generations. And then I get him a dragon-bone comb, and then a pair of elven slippers so he can attract a wife. Maybe it's a really wonderful story, but ultimately you're just a glorified imperial errand-boy.

So it's not good enough just to have a different story. You need some variety in the action. And that takes a lot of effort.

(Comment added by thyrr on Tue Sep 26 20:49:11 2006)

You could write a pool of action subplots that involve, say, a sword fight, a chariot race, escape from an exploding castle, etc. This is still as mindless as a summer action movie, but hey, it's not like MUDs are works of high art, and it keeps the action diversified.

So, a builder would choose different pre-coded "action sequence subplots" and write the story for the transitions.

You could write, say, PART 1: "You must recover the Statue of Macguffin from the Temple of Probable Doom." Item finding quest. PART 2: INTRO: "Just as you pick up the statue, Dr. Antag Onist shouts (some random taunt)." Game switches to part 2: the swordfight. After it registers a kill, the quest produces ITEM 47 STRANGE KEY that you find on the body. Going to a hidden room in the Temple triggers the next stage, and it shows the part 3 intro: "You discover in the documents in the room that the statue is in fact a diversion, and you actually need to go interrogate Mr. E Machina". Switch to find-the-person quest. And so on.

(Comment added by thyrr on Tue Sep 26 20:55:32 2006)

And hey, Oblivion gets away with this kind of stupid kill-this-fetch-that action and is actually decently enjoyable (at least the first time around), so maybe it's good enough.

Yes, exactly Thyrr! My point is just that. If the MUD is centered around one feature (or requires all players to use that feature repetatively), the feature is going to get old nomatter how great it is. Questing, by far, is not exempt from this. In my mind, the best MUD system would be to implement a good combat system, implement a hand-built questmaster questing system, create a diverse economy that would allow for varying professions and crafting, and create a number of very intricate and well thought out miniquests or extended-quests hidden at various points within the game. (Those are in no particular order... in fact, looking at it now, they're in reverse order).

*shrug* Oh well...

Best of Luck,
-Jess

Since this is brainstorming --

Take it on faith for a moment that an autoquest system is better than hand-built because it saves you some time and effort. There are no shortcuts, you must write the content, but you only have so much time, so you use an autoquest system.

However. The point to remember is that most autoquest systems are quite dumb. They don't know very much about what's happening in the game world, what npcs and pcs have done, really they could care less. They're just a vending machine waiting for a pc to push their buttons. What you, lazy coder, want to do is make the autoquest system aware of what's happening, so not only do you initially define rules and relations in the system, but allow the system to create new relations based on world events. Think about it. On a typical mud thousands of events occur every day. Granted some of these you will want to sift, particularly when Bubba clears the goblin village every fifteen minutes. But in your mud a vein of rich information flows that your system can mine on a daily basis, why not take advantage of that?

Anyway quests seem to be popular in this thread but perhaps we can talk about something different. One of my gripes with bases such as Diku is that many times mob behavior defies logic. Your pc just ravaged 2/3 of the town and in the very next room five mobs completely ignore you. Or your pc arrives in the town square covered in mithril armor from head to toe, a six foot long claymore strapped to your back, riding a glowing pegasus, with a coconut in one hand and the head of the troll chieftain in the other, and the town guard doesn't bat an eyelash. How about putting a little less effortr into creating another felar/felinus/felas cat race and a little more effort into coding mobs to act a little more intelligently than a corpse waiting to happen. Sure it's a little easier for newbies if the mobs are dumb, but it's not like your duck mob is suddenly going to respawn into HAL 9000 anyway.

...is make the autoquest system aware of what's happening, so not only do you initially define rules and relations in the system, but allow the system to create new relations based on world events. Think about it. On a typical mud thousands of events occur every day.
No, the only things that happen on a typical mud are interactions between a player and their environment. I don't believe I've ever seen a MUD in which mobs interact with one another unless there was a script written for that one particular mob to interact with the other... and even then, guard and gang SPEC_FLAGS are the only ones I can think of. If the case is that you've been able to create an environment where the game interacts with itself without manual scripting (like the actual world does), then that's a feature I would suggest stressing here as a good addition to a MUD, rather than relating it to questing. In fact, now that it's been brought up, that's the primary project I'm working on mentally at the moment... and have been for a couple months. I think I have it mostly worked out, but it's certainly something I'd love to see someone else do too. If you can get to a stage where the world behaves in this way, however, you're effectively at a stage where nothing should need to be custom built except those things which define certain aspects of the way the world interacts... That would be an interesting system.

As for the questing thing, I see that I am alone in my beliefs, so I'll take the hint and shut up. Regardless, however, hand-writting quest systems have always been, and will always be better in my mind, not only from the view of a player, but also as an admin. In that respect, it's definitely how I'm doing my system, and I'd personally like to see it done in many other MUDs as well.

As for the realism thing you proposed... I totally go for that, and is, once again, something I plan on implementing. It is, however, a pretty complex theme, given that first you have to create an environment that is aware of its surroundings, and its place in the world, and behaves accordingly. I.e. the guards first have to be aware that they're guards, and the commoners have to be aware that they're commoners, and as well, both the guards and the commoners have to be aware of the events transpiring and their meaning, and then act according to both. Without specific scripting, that's much easier said than done.

Best of luck in any case,
-Jess