QUEST GUIDE
===========

 1. Introduction
 2. Player perspective
 3. Quest philosophy
 4. Using random
 5. Team work
 6. Domain cooperation
 7. Riddles
 8. Technical considerations
 9. Cheat prevention


 1. INTRODUCTION
================

Coding quests is challenging and sometimes difficult. However, it is
very fulfilling to see players struggle to solve the riddles you have
presented to them. As with all code, coding a good quest is harder than
coding just any quest. What is a good quest in this respect?

Whether a quest is good or not as good does not depend on the amount of
experience you give out. It has to do with how challenging it is to the
player and whether the quest can be easily reproduced. Mortal players
are bound to talk to each other. Where it is only natural that they give
each other hints on how to solve the quest, or give hints on where to
look, it is a problem when players give each other complete walkthroughs.

When mortal players give each other quest-walkthroughs, we are speaking
about something completely different. That is spoiling the game, not only
for the players who do not want such help since they consider it a matter
of honour to solve the quest themselves. It is also spoiling the fun for
the wizards who have spent many hours designing and coding the quests.

A good quest in this respect is a quest that can take different forms,
so even though the big picture and the eventual task are roughly the
same, several challenging details are different each time someone tries
to do the quest. In order to help you in this respect, there are several
ideas we would like to present to you.

Some of the ideas presented here may seem very trivial to you, which is
a good thing. Naturally several of the things remarked here also apply to
the design of areas, NPC and other things. Just consider them and keep
them in the back of your head when designing a quest. Discuss your ideas
with others and remember one of the most important things in quest design
remains: use your imagination and use your common sense!


  There is one other thing. Do not be reluctant to ask other people for
  help, for ideas or for aid in case of any problems. Other than with the
  personalized macros, there is no coding aid in this document, so in case
  of any questions, don't let the fact that you don't see how to code an
  idea directly keep you from using the idea. There are a lot of people
  out there who are more than willing to help you if you ask them nicely.


 2. PLAYER PERSPECTIVE
======================

When a player tries to solve a quest, there are various things the player
should be able to count on. They have to do with the playability of the
game and the way players can expect code to be designed and implemented.

a. A player should not be killed without warning.

   Example: A room with three exits, two of which lead to certain death
   and the third to reward, is unreasonable without some kind of hint. This
   hint does not have to be obvious, it might be hidden in the description
   of an item in the room, but it should be there.

b. A player should not have to do unlikely things.

   Example: The player has to wait in an empty room for five minutes to get
   a hint or for something else to happen. Or to find a hint, the player
   has to examine the road in the fifth of ten rooms of road connecting two
   places when that road is not referenced elsewhere or when the other nine
   rooms do not even define an item "road". It might be fair enough when the
   other rooms include a sentence like "Here you cannot see anything special
   on the road."

c. A player should not have to do boring things for the sake of it.

   Example: It might be fun to put a four-discs tower of Hanoi puzzle into
   the game, but not an eight-discs one. Mazes are a special case of this.
   See "man mazes".

d. A player should be able to solve a quest without having to resort to
   trial and error.

   When a quest involves something that is not general to the game, there
   should be a way for the players to find out what is expected of them.
   This is especially the case if the same non-general thing can be done in
   other domains as well and other commands are used there.

   Example: When the player has to cook a stew with herbs, it should be
   possible to find out which herbs to use without cooking the stew with
   many different herbs until one has found the correct combination. One
   way to do this is have a cook-book somewhere that people can read.

e. A player should not have to use exactly the right syntax, reasonable
   synonyms must be possible.

   The point of a quest is that players find out what to do, not that they
   guess the unique correct syntax. Support more than one syntax, use
   parse_command() to allow the player to use articles and prepositions.
   Use error messages to give a hint for the correct syntax. When the short
   or the long description of an object uses adjectives, add these
   adjectives using add_adj().

   Example: A command like "climb through window" is not easy to find when
   typing "climb window" returns "What?" or "Climb what?". Better would it
   be to make that preposition optional. A synonym like "enter window"
   could also be used. If there is a "woven wall hanging" in a room, it
   should be possible to call it "tapestry" as well as "curtain".


 3. QUEST PHILOSOPHY
====================

For quest design, several fundamentals can be identified. For good quest
design and coding, these have to be taken into consideration.

a. Atmosphere and background.

   Remember to stick to a medieval setting, theme, and atmosphere. See
   "man GENESIS". If your domain has a theme, stick to that theme. Fit your
   quest into the rest of the domain instead of creating a large new area
   at the periphery.

b. Plot.

   A quest should be more than just collecting a dozen items from different
   locations. There should be a purpose behind it. In this regard the
   zodiac quest of Terel is worse than the (removed) katana quest, since the
   former does not explain how the different parts belong together and why
   you should be rewarded for pressing six buttons on a door.

c. Structure.

   If a quest consists of several parts, does one have to solve all parts
   one after the other in a fixed sequence, or is it possible to work on
   other parts when one is stuck with one problem? In general, it will not
   be possible to make all parts so that they can be solved independently
   from all other ones, but some freedom in choosing the sequence is better
   than none.

d. Target.

   Not all quests need to be solvable by all players. A quest may require
   some minimum in skills and stats or make other demands one the character
   that is played, so that it is impossible that a novice can solve a quest
   written for veterans. Criteria like alignment, guild affilation, race
   or gender can be used. A solution that works for an evil player might
   actually harm a good player. To be fair to all players, you can create a
   second quest with a similar assignment for a mutually exclusive other
   group of players, though naturally a different solution. 

e. Density.

   Make everything interesting! ;-)

   Add information to rooms and objects that has nothing to do with the
   quest. Make it possible to examine details. Add an item description if
   something is mentioned in the long description of an object or a room,
   and keep the long description itself short. It becomes rather obvious
   that there is a quest somewhere if there are two dozen bare rooms and
   one room filled with add_item()'s and other interesting hints or things.

f. Integration.

   When a new area is being coded, build quests into the area from the
   beginning. Players will in general thoroughly search an area just once.
   After they meticulously examine a road, they will not likely do so again
   later to see if something new has been added to the road, unless there
   are obvious changes to the area. Changes in the long description or map
   of the area are noticed and can trigger people to search further. New
   information hidden in add_item()'s or searches of items, are not likely
   to be found.

g. Rewards.

   Of course it is nice to reward a player with something more than just
   experience points. But think twice before using yet another autoloading
   object. Other possible rewards can be some food or some drink, money, a
   weapon or an armour, or perhaps access to an otherwise closed part of
   the domain.

h. Wizard cooperation

   When designing or coding a quest, consult fellow wizards and use them
   as sounding board for your ideas. It is generally a good idea to have a
   fellow wizard test your quest after it is coded. This peer review will
   help you finding bugs or lead to other suggestions for improvement.

A quest should be interesting for the player that tries to solve it. Once
the player has solved the quest, there should be a feeling of achievement,
so the good quest is also difficult and it might even be dangerous.


 4. USING RANDOM
================

There are various ways to use random in quest design. They can help to make
the quest interesting and challenging. In addition to that, random is one
of the few main means that can be used to prevent people from giving easy
walkthroughs.

a. Random with skills and stats.

   Make use of random or tasks. That means that people may have to use
   several attempts to succeed, but it will also give people with slightly
   less skills or stats a chance to success. See "man tasks" for more
   information about using tasks. In general, tasks are less randomised,
   though people use it because some find it more realistic.

   Example: If you have a wall that people with (SS_CLIMB > 40) may climb,
   you can also make the function (SS_CLIMB > (35 + random(15))) which will
   make the limit range from 35 to 49, so people with slightly less skill
   have a small change of success and people who have higher skills have a
   fail chance too. However, excellent climbers will always have success
   and bad climbers will always fail. The use of a threshold is important
   here. Using something like (SS_CLIMB > random(50)) is not a good thing,
   since it will even allow people with a skill of 1 to succeed just by
   being persistent.

b. Uncorrelated random.

   Make use of random for things, locations and events. If all objects and
   all other things related to the quest are always in the same place and
   react the same way, it will be very easy to reproduce or redo the
   quest.

   Example: Suppose you have a torch in a locked chest somewhere, you may
   put three chests in different (not necessarily adjacent) rooms and
   randomly put the torch in one of those three at creation. The player
   who goes to chest A since someone told him that may very well find
   nothing since the torch is in chest C that particular time. Ah, and the
   chests are locked. How about randomizing the lock of the chest at
   creation, forcing the player to test four keys that are available from
   different locations.

c. Personalized random.

   Make use of personalized random. This means that for player A the
   particular part is always the same and for player B is it also always
   the same, but it is different for players A and B.

   To do this you need the macro NAME_TO_RANDOM(name, ident, range) that is
   defined in #include <math.h>. The <name> is the lower case name of the
   player, <ident> is a (large) unique number that should be different for
   each quest or quest-part and finally <range> is the random you want the
   number generated from. This macro will return a value in 0..(range - 1).
   The fun is that even for the same name and range the outcome will be
   different for different ident numbers. However, every time you call the
   macro with the same arguments, the same random number will be returned.

   Example:  The task may be to get a coloured shield from somewhere, but
   player A will need the red shield whereas player B will need the blue
   one.

   #define SHIELD_COLOURS ({ "red", "blue", "black", "white", "green" })
   #define SHIELD_IDENT   198752652 /* the large number. */
   #define SHIELD_RANGE   5         /* the number of shields. */

   Now if we test some assignments we get the following:

   NAME_TO_RANDOM("mercade", SHIELD_IDENT, SHIELD_RANGE)  -> 0 (red)
   NAME_TO_RANDOM("tintin",  SHIELD_IDENT, SHIELD_RANGE)  -> 3 (white)
   NAME_TO_RANDOM("olorin",  SHIELD_IDENT, SHIELD_RANGE)  -> 0 (red)

   As you see, Olorin and Mercade have to get the same (red) shield, where
   Tintin must get another shield (the white one) in order to solve that
   part of the quest. Now if Tintin takes the easy way and asks Mercade for
   help and he returns the red shield to the knight, that knight will not
   be too friendly with him since that was not the correct one to return.

   Now if we also have a AXE_IDENT of 198752651 (i.e. one lower than the
   SHIELD_IDENT), you will notice that the names mercade, tintin and olorin
   will respectively yield 2 (black), 4 (green) and 1 (blue), so you see
   that the numbers are absolutely random as long as you keep the IDENT
   number secret.


 5. TEAM WORK
=============

Requiring team work increases the chance that one player reveals at least
part of a quest solution to another player. On the other hand, team work
should be encouraged, since interacting with other players is that feature
of muds which makes it differ from adventure games. Moreover, having to
coordinate the playing of two or more players, all having their own mind
(hopefully!) and interests makes it more difficult to use fixed recipes
how to solve the quest. There are a few ways to involve team work.

a. Mutually exclusive activities have to be carried out.

   Example: There is a trap-door with a lever. Player A needs to pull up
   the trap-door for player B to enter. The moment player A releases the
   lever, the door will close again so if he would be alone, player A would
   never be able to enter the door before it closes again.

   Example: In a mine, one exit has been blocked by a large rock falling
   down from the ceiling. The player sees a rope on the floor running under
   the rock into the next room. When the player tries to pull on the rope,
   this has not effect since the rock blocks the rope, but when the player
   lifts the rock, he cannot pull on the rope at the same time.

b. Players of different gender, race, etcetera, need to do something.

   With this, one has to be careful that the requirements are still general
   enough. When a male and a female player have to do something, everyone
   can still participate, though when you require that "a hobbit and an elf"
   do something, this rules out many players.

   Example: In a temple, some obscure ritual needs to be performed by one
   male and one female player to please the local deity and only then, he
   shall share some of his wisdom with the people who perform the ritual.
   Or perhaps a pure person (someone who has not been killed before), a
   young player, etcetera.

c. Require the (physical) capacity of two or more players.

   A way to make a team quest is to require the combined capacity of two or
   more players. This can be done two ways. Either by doing something that
   can only be done with more than two hands, or by allowing multiple
   players to for instance combine their strength pushing open a door. With
   this one has to be careful, though. Due to the inflation of stats, it is
   highly likely that a player will be able to do it alone. Thus setting
   the limit at something outrageous will only disable normal players from
   doing what needs to be done.

   Example: The combined strength of two or more players is needed to push
   a door open. To counter the stat-problem you can always require at least
   two players before counting the stats.

   Example: Three or more players have to pull on edges of a sheet to keep
   it stretched. Then, someone who is trapped on a cliff can safely jump
   down.


 6. DOMAIN COOPERATION
======================

Quests do not necessarily have to be concentrated in one area. To make it
more challenging and interesting, a quest can be spread throughout a domain
to make it less easy for a player to put it all together. In a similar way
domains can cooperate. There are two ways domains can cooperate with the
design and implementation of quests.

a. Spread parts of quest or items over domains.

   Example: Knowledge about on old ritual can be found in the library of
   the city in another domain. Or a alchemist who can transform one item
   into another.

b. Allow special items of other domains to work in a quest.

   Ever so often, a quest requires something to be done with a special
   item. An item that is not generally used in the game. These items are
   identified by a special name added to it. Domains can agree on such a
   name together, so the special item of one domain can also be used in
   another domain, rather than that the player will need the particular
   special item that the coder of the quest assigned for it.

   Example: For a mining quest, a player needs a chisel. The author of the
   quest will normally make a chisel available somewhere. By allowing all
   items that can be identified with item->id("chisel"), i.e. that have
   the the name "chisel" added to it, a player can use any chisel he has
   and not just the one the author added. Would the designer have chosen a
   name "_chisel_for_my_quest_2385_" it would not have been possible to use
   another chisel, even though other chisels are available.


 7. RIDDLES
===========

Riddles are very popular since they are easy to use. Moreover, they can
make a quest difficult and make it harder to tell the solution on quests
when riddles are involved. However, when using questions, problems or
riddles, there are a few things that might be helpful to remember.

a. Make riddles general.

   This means that you should not require (specific RL) knowledge that is
   not generally available to the players from geographically spread
   locations or that cannot be considered common knowledge among adult
   players. Also, the riddles should mainly require intelligence and the
   ability to think logically. Requested factual knowledge should be linked
   to the game and if possible be available in the game too.

b. Collect many riddles.

   When you have only one or a few riddles, the answers to those riddles
   may become known quickly. Collecting a large number of riddles to choose
   from, will make it harder for people to answer them all (and share the
   answers). These questions should preferably be related, though, or
   centred around a common theme. A way to get many riddles is to have them
   generated through a particular algorithm. This is especially true for
   numerical riddles.

c. Assign one or more riddles to a player.

   A way to make it more difficult for players to gather the solution to
   many riddles is to assign one or more riddles to a player to solve. This
   will also prevent players from trying and trying again until he finds a
   riddle that he can solve. These selected riddles can then be remembered
   for a player. The word remembering does not necessarily mean that those
   remembered riddles are saved to disk, but the riddles a particular
   player has to solve can also generate using the macro NAME_TO_RANDOM
   described above.


 8. TECHNICAL CONSIDERATIONS
============================

When designing and coding quests, there are several technical considerations
to keep in mind.

a. Regeneration

   After being solved, all quests should refresh themselves within a certain
   time. This is usually done through the reset_* functionality. This goes
   for the status of the quest being "solved" and "unsolved", but also for
   the different items that may be necessary that should become available.
   Nothing may depend on the mighty Armageddon to be regenerated! The uptime
   is an unknown factor. With new computer equipment and more memory, we may
   well have an uptime of a week in the future.

b. Doing a quest in parts.

   Players do not necessarily have to solve a quest in one go. This should
   be taken into consideration. A player may start a quest before a reboot
   and finish it afterwards. It is also possible that knowledge is gained
   one day that is used a week later.

   Example: In a library, a property is set in a player when he reads a
   particular book. This may be meant to check if the player himself found
   the information rather than it being heard from a friend. However, if the
   player pondered the information for a week before being able to use it, he
   may suddenly find himself unable to complete the quest.


 9. CHEAT PREVENTION
====================

If people use despicable ways to gain some quick experience, there is
nothing that prevents you from being mean in a friendly way. This does not
mean coding death traps, or harm players severely in another way without
notification, but there are enough things to come up with that will prevent
people from giving out walkthroughs. There is no rule whatsoever that
prevents you from altering an area or a room months after it is coded, or
have such changes automated.

   Examples: What is easier than to (manually) alter the connection between
   two rooms in a road or forest, from north-south, make it norteast to
   southwest. All people who use do statments or just type a long time
   ahead, will find them in a location they hadn't imagined themselves
   before. This will especially be the case if you add rooms and exits that
   allow the player to continue running for a while after the missed the
   turn, ie: n, w, ne, nw, n, nw becomes n, w, <fail> nw, n, nw, <panic>.
   This is done by adding an exit nw to the room where the player expected
   to go ne.

   Something even simpler is make people trip with a small chance, or at
   creation of the room, make a tree fall over with a 5% chance or less,
   so the player has to use the climb command to advance, rather than the
   exit command.

Some like to add a check for game-age to their code. This would prevent
people from creating a "second" character or assisting friends building a
new character and running through quests a lot quicker than people would be
expected to do if they were honest and independent new characters. However,
there is little explanation in the game theme or environment for such a
check. The best message possible would be something like "You are not
worthy to do this." or "You are not experienced yet to do this", and that
is not too elegant.
