I am in the last stage of my database development and need to create a quest system for an MMO-RPG, which is the one thing i have never done before...

So far the only way i can think of to do this is to have a table with every quest conversation/achievement which is linked through to the next part in the quest. along with a link to my npc table of which npc the quest is selected from.

How would one go about keeping track of what quests the character has completed? would it require a quest sheet (bool variables for each quest) for each character?

ex:

npc----

-map_id //which map the character is on

-quest_id //linked to npc when talked to , displayes message

//other stuff for npc

quest---

-quest_id

-quest_message

-quest_rewards

-quest_next //linked to npc which holds the next quest part

completion_sheet

-(lists all quest ids and holds 1 or 0)

so, when i talk to npc it checks to see if completion sheet for the quest id is already done, then if it is, nothing happens, else, it calls the quest message and displays it, then you find the next guy and get the reward... Does it make sense? How would I keep up with say... killing a specific number of monsters or collecting something?

I like the solution proposed to this question the last time it was asked: that a quest system be handled much like an inventory. When an NPC gives a character a quest, he/she literally gives the character the quest

While the character has the quest in his/her quest-inventory, he/she cannot be given that quest (to prevent a character running the same quest multiple times at once), and repeatable quests could have the character either drop the quest or give the quest back to the NPC (one idea thrown out was that the NPC had a limited inventory of quests, like one/character, so giving it back would allow him/her to give it back again when you wanted to repeat the quest).

The treat a quest like an item approach sounds pretty good but it might start getting a bit more complicated if you have quests that might be repeatable only a fixed number of times. An example, NPC A wants 20 Units of Iron. Maybe after doing this quest 5 times NPC A has plenty of iron and doesn't want any more. Under the "item" approach you would most likely give the NPC 5 of these quests to hand out (and that might work out just fine). However my approach has always been to treat the entire questing system as more of a global management type system. That is to say that the "QuestManager" simply lists the generic details of each quest such as where do you get it, what does it require, where do you turn it in and how many times it might be completed. In more advanced systems maybe you can also add in the prerequisites, times of day when it is available and so on. None the less, in a single player game it seems to be easier to manage the quests as a complete system simply recording when and or if the player has completed it.

Sorry it's not a bit more elaborate, but hopefully this will at least portray my concept and give you an idea on how to build something similar. I wouldn't discount the above suggested approach as it would most likely work wonderfully in most game's, just see something that might impose limitations and extended hassle if you are developing a complex questing system.