29 Jun, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
Ok, so I'm at the point to where I want to fully implement a Quest system. Most systems I've seen
are more or less community quests, like "First player to get BLANK wins 1000 gold!" And they are timed
or whatever. This is fun and all, but i've always wanted a WoW type quest system, perhaps not exactly, but
along those lines. So I am using a QuickMud as the platform, with quite a bit of customization, and I am wondering
what you guys think about actually building a custom quest system, OR just using MobProgs to accomplish this.

I dont know much about MobProgs but it seems that it might be quite effective without having to reinvent the wheel
or hardcode something similar. Have any of you done this? Or do you prefer to fully customize your quest system?
If so, how difficult was it?

I welcome all lines of thought :wink:
29 Jun, 2009, Runter wrote in the 2nd comment:
Votes: 0
You're going to really want a scripting engine for this. You're going to spend all your time writing code for every unique quest otherwise.
Lua and python seem to be in vogue right now for doing this, but even writing your own simple syntax is possibly acceptable.
29 Jun, 2009, Idealiad wrote in the 3rd comment:
Votes: 0
There's been some pretty interesting threads on quests at MudLab. This one comes to mind:

http://mudlab.org/forum/viewtopic.php?t=...


eta: I came across this old thread too, it'd be neat to see it incorporated into a quest system: http://mudlab.org/forum/viewtopic.php?t=...
29 Jun, 2009, JohnnyStarr wrote in the 4th comment:
Votes: 0
Runter said:
but even writing your own simple syntax is possibly acceptable.
Well, my plan is to use MobProgs which isn't as powerful as Lua or Python, but it
does work pretty well for light scripting on the fly. Ideally my quest system will have quests such as "Kill 10 orcs, collect 5 orc rings" after doing these you would return to the quest master npc and get your reward, i havent tried yet but it seems like MobProgs could do this no sweat.
29 Jun, 2009, Runter wrote in the 5th comment:
Votes: 0
staryavsky said:
Runter said:
but even writing your own simple syntax is possibly acceptable.
Well, my plan is to use MobProgs which isn't as powerful as Lua or Python, but it
does work pretty well for light scripting on the fly. Ideally my quest system will have quests such as "Kill 10 orcs, collect 5 orc rings" after doing these you would return to the quest master npc and get your reward, i havent tried yet but it seems like MobProgs could do this no sweat.


All of those examples make it easy to design system with templates. The generic scripting engines are more useful for giving your builders the power to design quests rather than base them on existing templates.
29 Jun, 2009, David Haley wrote in the 6th comment:
Votes: 0
Quote
Well, my plan is to use MobProgs which isn't as powerful as Lua or Python, but it does work pretty well for light scripting on the fly. Ideally my quest system will have quests such as "Kill 10 orcs, collect 5 orc rings" after doing these you would return to the quest master npc and get your reward, i havent tried yet but it seems like MobProgs could do this no sweat.

Work with mobprogs for a while and then come back – we'll see if you still think they're so great and can do this kind of stuff "no sweat". :wink:

Here's a simple question: how do you track quest state using mobprogs? How do you check if player X has completed Y steps of quest Z? The mudprog syntax only allows one argument to the if-check "function" (I cringe at even using that word w.r.t. mudprogs) and one on the right-hand side of the operator.
29 Jun, 2009, elanthis wrote in the 7th comment:
Votes: 0
You don't technically really need a script system, to be honest, if you're going for the kind of simplistic FedEx-style quests WoW and almost every other MMO/MUD relies on. You can use a very simple description of a quest stored as a list of structs that represents a series of steps with each step having a set of requirements. For example, the quest Kill Orc King Mandy might simply have a single step with requirement KILL_MOB and the mob_num set to whatever your Orc King Mandy is. You could extend it to have failure conditions too, such as DEATH_MOB and then providing the mob_num of some NPC you were supposed to protect from the Orc King. And so on.

You can then extend mob progs with a few calls to check if a player has a certain quest active and which step the player is on for any particular quest, as well as calls to add, complete, or fail a quest or to change the current step number. Then you can work dialog into quests relatively easily, within the limits of what mob progs can really do for dialog.

This in turn makes it a lot easier to develop quests than a full scripting language, because you can come up with some simple file format (or even better, a good OLC tool) for quests that doesn't rely on builders scripting the same kind of thing over and over and over. They could just whip up a .quest file that reads something like:

Kill Orc King Mandy~
1
Kill Orc King Mandy~
require KILL_MOB 445
2
Get Reward From Cindy~
require SPECIAL 0
fail MOB_DEATH 546

Add in any number of special requirements you want. You can make ones that require killing a specific number of a certain mob, getting a certain set of objects, etc. You will most likely end up growing a few additional features if your quests become interesting, but you can do a lot with very little here.

The neat thing with a system like that is that it is complementary to a real script environment. If you do decide to add Python or Lua or whatever, you can simply allow scripts to dynamically create quests or quest steps, alter quest requirements or fulfill steps, and even allow for "quest requirement plugins" so that builders can extend quest system capabilities with a script where needed, and stick to the simpler system where it's not (or where a plugin already exists for what they need).
29 Jun, 2009, David Haley wrote in the 8th comment:
Votes: 0
Well, if all quests look the same, then yes, you're better off with a specialized system – whether it be implemented in C++ or in Lua. Nick's 'task system' (which he published on his forum somewhere) is an example of such a system written in Lua, and it works rather nicely for this kind of relatively straightforward quest structure.

My 'vision' for quests is basically a collection of nodes that can be customized and stuck together in flow charts. So the simple quests would be made from one or two very standard nodes (kind of like what Elanthis showed) whereas you can make far more complex quests with all kinds of branching depending on all kinds of things using more nodes that can be conditioned on previous things, etc.
29 Jun, 2009, Scandum wrote in the 9th comment:
Votes: 0
staryavsky said:
I dont know much about MobProgs but it seems that it might be quite effective without having to reinvent the wheel
or hardcode something similar. Have any of you done this? Or do you prefer to fully customize your quest system?
If so, how difficult was it?

Emud's mobprogs are quite effective when it comes to this and the license is easy going:

http://slackhalla.org/~emud/codebase

I also wrote a small snippet for Smaug a while back.

http://www.mudbytes.net/index.php?a=file...
29 Jun, 2009, JohnnyStarr wrote in the 10th comment:
Votes: 0
Well, thats a good point David.

Now, i havent done it yet, but i was planning on checking for each requirement. Apparently you cannot do this?
I was thinking if the quest required you kill 5 trolls, it would check your kill log and verify this, i might add that i'm
certain that STOCK MobProgs might not have all the exact details i might need, but using the GIVE script would
work great for giving them the reward and stuff.

I also like Elanthis' idea as well, i'm just not that savy with embedding an additional language and was hoping that
it might make more sense to *add to MobProgs what it does not have, rather then overhaul the mud to use Lua.
I did by the way read up on Nick Gammons site, but i have to admit that it is very intimidating, especially because its
documented for SMAUG and not ROM.
29 Jun, 2009, David Haley wrote in the 11th comment:
Votes: 0
The problem with mudprogs is that eventually it becomes incredibly difficult to add to them, because the underlying parsing engine etc. is just fundamentally broken. I'll admit that I'm assuming that the ROM implementation is similar to the one in SMAUG; it's possible that ROM has a far nicer system, but the one in SMAUG is just plain painful to deal with. If not for breaking compatibility, it would probably be easier to just rip it out and write a simple top-down parser instead.
29 Jun, 2009, KaVir wrote in the 12th comment:
Votes: 0
Runter said:
You're going to really want a scripting engine for this. You're going to spend all your time writing code for every unique quest otherwise.

Scripting languages are code as well, so you're still going to have to write a load of code. The main advantage of scripting languages is that you can let other people create the mobprogs for you without (1) needing access to your code, or (2) breaking the mud with their bugs. A simple scripting language also tends to be easier for non-programmers to use, although simplicity can sometimes come at the price of flexibility.

Personally I just hardcode the lot - although my trigger system is set up in a pretty generic way, so I could easily mix-and-match hardcoded and softcoded triggers should I later choose to add support for a scripting language. I don't have any builders though, so it's not really a priority, as I'd be the only one using it (and I prefer C++).
29 Jun, 2009, Runter wrote in the 13th comment:
Votes: 0
KaVir said:
Runter said:
You're going to really want a scripting engine for this. You're going to spend all your time writing code for every unique quest otherwise.

Scripting languages are code as well, so you're still going to have to write a load of code. The main advantage of scripting languages is that you can let other people create the mobprogs for you without (1) needing access to your code, or (2) breaking the mud with their bugs. A simple scripting language also tends to be easier for non-programmers to use, although simplicity can sometimes come at the price of flexibility.

Personally I just hardcode the lot - although my trigger system is set up in a pretty generic way, so I could easily mix-and-match hardcoded and softcoded triggers should I later choose to add support for a scripting language. I don't have any builders though, so it's not really a priority, as I'd be the only one using it (and I prefer C++).


The point was you can let builders write code in a sandbox in a language suited for rapid development.
29 Jun, 2009, Idealiad wrote in the 14th comment:
Votes: 0
Right, but as KaVir mentioned he has no builders. I can think of a couple of muds with one main developer where this also might be the case.

However I think the idea that builders will create quests quickly with a scripting language may not be accurate. If you really want rapid development of quests than an OLC template system sounds better to me.
29 Jun, 2009, Runter wrote in the 15th comment:
Votes: 0
Idealiad said:
Right, but as KaVir mentioned he has no builders. I can think of a couple of muds with one main developer where this also might be the case.

However I think the idea that builders will create quests quickly with a scripting language may not be accurate. If you really want rapid development of quests than an OLC template system sounds better to me.


KaVir wasn't defending using a poorly designed prog system, either. ;)
29 Jun, 2009, JohnnyStarr wrote in the 16th comment:
Votes: 0
As far as ROM goes i dont see the problem with something simple like, if one of the requirements is "10 orc hands" you could do the on_give trigger and run the prog that evaluates the other requirements.

I think if I were to add a few triggers that examine the players quest progress the rest would work.

Like, if the quest was "bring me 4 orc bones" you could give the 4 bones to the QM, then they could give you your reward.
29 Jun, 2009, Runter wrote in the 17th comment:
Votes: 0
staryavsky said:
As far as ROM goes i dont see the problem with something simple like, if one of the requirements is "10 orc hands" you could do the on_give trigger and run the prog that evaluates the other requirements.

I think if I were to add a few triggers that examine the players quest progress the rest would work.

Like, if the quest was "bring me 4 orc bones" you could give the 4 bones to the QM, then they could give you your reward.


Fair enough. And if that's absolutely all you want for your quests then you'd be fine. Just keep in mind it becomes difficult to maintain code when you want builders to be able to do things like:

1. Enter the ruins.
2. Find the lost explorer.
3. Defend the explorer for 2 minutes.
4. Escort the explorer back to the expedition camp.
29 Jun, 2009, JohnnyStarr wrote in the 18th comment:
Votes: 0
thats very true, thats why i would have to add a QUEST_DATA structure and link it to pc_data so that we could keep track of the progress, then we could just add some functionality to the mobprog.c file and there you go.

NOT saying thats going to be a cakewalk, but IMO its faster than writing a bunch of Lua extensions to ROM

As far as Other Builders, I will take care of that by writing a Script builder that will be part of my user friendly ROM builder for MS Access. This way all vnums and commands are dynamically linked to the db, so if something changes, it will give you the option of updating the mob prog as well, i figure this will cut down the risk of builders writing bad scripts.
29 Jun, 2009, elanthis wrote in the 19th comment:
Votes: 0
Yeah, you generally will want three different ways of dealing with world data for quest requirements and failure conditions:

1) Polling
2) Events
3) Scratch Data

You need polling for querying the world for events that may not occur near or in any relation to the player, mostly for if you have a fully shared world where other players could interfere with a quest. Events are for checking when certain one-off conditions happen, especially for Kill 'Em quests. (Most games respawn all NPCs, even "unique" ones, and if quests are repeatable, checking a kill log would be a bit broken.) The scratch data is for when you need to keep track of "has he talked to so-and-so" or whatnot. Using a quest step system you can eliminate a lot of need for scratch data, honestly, although truly complex quests may end up being easier to implement with scratch data rather than a web of quest steps.

I recommend you take a look at Bethesda's games (Oblivion, Fallout 3, etc.) to see how their quests work. It shows off what I'm getting at pretty well.

You really should not need to have builders script anything complex for a quest 95% of the time. A number of well thought out quest requirement types can easily handle a large variety of needs. The hardest thing to handle will be when you have combinations of compound requirements (get 5 drake roots OR 3 orange sodas and 3 rabbit feet), but personally I think complicated requirements like that are best avoided anyway.

The problem with relying on a script system too much is that it makes building far harder. A well designed quest system makes building quests similar to building a castle with block, while relying on a script system means that the builder has to go chop down a tree and cut it into blocks before he can even start on the quest. It requires more work, more learning to get right, and makes it too easy to get wrong through syntax errors, incomplete conditional coverage, lack of error/failure handling, the need for a real debugger, etc. A quest system – especially with a decent OLC interface – makes it easier to understand a quest at a glance (it basically is displayed as a real flow chart instead of as a ton of probably poorly-written lines of script) and hence easier to debug and maintain and also makes it harder to introduce bugs (the quest components Just Work™ and don't need to be glued together manually).

You still probably want a script system. I'm not arguing against that, obviously. I'm just saying that you are far better off using a real quest system with its own code that works independently of any builder scripts.
29 Jun, 2009, Splork wrote in the 20th comment:
Votes: 0
I wholeheartedly agree with Elanthis. I think the best system is having both options and not depending entirely upon the independent scripting language. Especially since the majority of your builders will never be able use it.

We have both options at SlothMud. The problem is, when a quest using our custom scripting language(http://www.outgribe.com/jason/mudl/index...) somehow comes up broken and the founding builder is no longer active or with us, we find ourselves having an incredibly difficult time fixing it.

Splork
0.0/21