Crashcourse - Part 11

---

We haven't discussed quests yet, so I guess it's about time... Quests are really easy to code if you can code normal areas. There are just a few new aspects to consider.

First of all, a quest should be centered around some kind of task or mission that has to be completed by the player. For instance, the player has to save the princess from her evil stepfather. That is the ultimate goal of the quest, but you may have to work your way through several smaller tasks / missions to complete the quest.

The quest should contain smaller (and larger) puzzles the players have to solve to complete the tasks at hand. A quest doesn't neccessarily have to contain that many puzzles, just try to force the player to use his/her braincells once in a while. ;-)

The player should be presented with small hints here and there, making it possible to figure out just what he/she has to do to solve the quest.

The opening text (in the guild) should contain a brief description of the quest and basic directions of how to get there. It may be a good idea not to write too specific information here, try to make it sound interesting without giving away too much of the plot. It's more fun if the player figures it out one piece at a time. The directions should also not be a specific route of how to get there, something like "somewhere south of M'Loria" should be plenty. ;-)
You should also attach a note to the text if this quest requires a lot of hard killing. If a newbie player tries to solve a really tough quest, he/she may die in it and soon just give it all up.

Quests shouldn't contain any lethal traps of any kind. The quest should encourage the player to investigate further, not disintegrate him/her.

The quest should only be possible to solve once per reset(usually twice an hour).

THE QUEST MUST WORK AND BE POSSIBLE TO SOLVE ONCE PER RESET! This implies that the whole quest should reset at the same time, it should not reset one part at a time. This is not totally neccessery in all kinds of quests, but you should try to accomplish it.

There are mainly two types of quests: single-player and multi-player. Single-playerquests means that only one person may attempt to solve it at any time and that he/she shall solve it on his/her own! In multi-playerquests however, players may party through the quest, and in fact, in some multi-player quests, more than one player is _needed_ in order to solve it. If your quest is a multi-player quest, you MUST make a note of it in the opening text in the adventurer's guild.

Okay, time to look at how it is done, codewise... There are only two new functions to consider, query_quests() and set_quest(). query_quests(questname) will return true or false depending on if the specified player has solved the quest or not. Very useful for disallowing players to solve the same quest several times. set_quest() add the quest to the player's questlist PERMANENTLY. The only way to remove a quest is by editing the player's playerfile.

So make sure you don't add that one function to your quest before it's ready to be implemented into the mud. Comment it out when you and the QC is playtesting the quest.

Properties are especially important in quests, so make a mental note of this: questitems must all have the property hidden set so that when the item is sold to the shop, it'll vanish. If some parts of the quest should be unavailable to players that have already solved the quest, add the property no_telein(or even no_teleport) to the rooms.

I have included a small questexample for you to look at. It includes a file called quest_file.txt which contains the quest description. I'm not going to tell you anything about the files. You should now be able to figure it out all by yourself. If you however don't understand it all, don't hesitate to ask.

Most of it should be pretty easy to figure out, maybe except for the QP line. How many questpoints should a player receive for a quest? Now, that's a tough question. To make it easier, first look at how tough the monsters you have to kill in the quest (if any) are, and add a little for them. Then you look at the puzzles, are they hard to figure out? Add a little for them. How big (in rooms) is the quest? Then, finally you may try to compare your quest with the other quests in the mud to try to see how much QP you should get for solving your quest. If you're not sure how much to give, just set what you think is fair, and believe me, the QC Arch will adjust it, if needed. ;-)
You should keep one thing in mind, though. Questpoints need not be the only reward from a quest. You could just as easily add a small (or big) reward yourself. Give the player extra cash, more experience points, a special item or boosted stats for a little while. Use your imagination. Just try to balance this extra bonus with the amount of questpoints the player receives.

I think we have covered most of it now, but if something is forgotten, don't be afraid to ask your nearest QC Arch... Hopefully I'm not around... ;-)

! BUG ! In one of the files is a design bug. Can you spot it? Go, look for it - don't read any further!

Ok, it's not easy to find if you don't know what you're looking for. But take a simple example. Imagine the quest with a huge boulder instead of the lake. You may find an ancient scroll with a spell to move the boulder aside and afterwards you can get to the troll. Well, should work fine BUT what if we reset the boulder? It may be that the player is still "chatting" with the troll and now he's trapped. Oops, even if he could quit easily he would loose all his eq - that's not very good for the players morale. In our lake-example the player can't be trapped - but if the lake resets while he's on the other side he may swim back anytime BUT he'll see a frozen lake on the western shore. How could we avoid that?
Think about it, I'm sure you'll find an easy solution or even more than one. If not - feel free to ask :-)

---