Quest System

Developers
2004-12-26
2013-04-22
  • Mike Anderson

    Mike Anderson - 2004-12-26

    OK, I've been trying to figure out a decent quest system and wanted to throw a few ideas around. Objectives are:
    - Support the development of a game storyline
    - Allow random quests to be created that are still interesting and meaningful
    - Allow complex quests to be managed
    - Be relatively isolated from the rest of the game engine, so we don't have lots of hard-coded stuff that is quest-specific
    - Let the player review a list of current quest objectives in case he/she forgets

    Basically we need to hook into a number of possible events:
    - Picking up an item
    - Killing a monster
    - Chatting to an NPC
    - Completing/Failing another Quest
    - Others?

    My current idea is that Quests should be special objects (descendants of BaseObject?) that can "hook" into the above events when they are awarded.

    There would be a couple of "factory" messages that could be used to generate quests programmatically. e.g.

    Thing someMonster=Lib.create("skeletal dragon");
    ....
    Quest a = Quests.killMonster(someMonster);
    Quest b = Quests.talkTo(someNPC);
    b.set("Reward","magic mushroom");
    Quest c = Quests.giveItem("magic mushroom",anotherNPC);
    c.set("Reward","Yanthrall's Sword");

    Quest d=Quests.combine(a,b);
    Quest e=Quests.combine(d,c);

    hero().addQuest(e);

    The hero now has a quest to kill a specific skeletal dragon, talk to someNPC to receive a magic mushroom, then give the magic mushroom to anotherNPC to receive Yanthrall's Sword.

    Does this make sense? Comments appreciated, I'd like to start work on implementing this in the next few days.

     
    • Dragonlady

      Dragonlady - 2004-12-26

      I've been thinking about that the last several days when I've been killing the trees. Those things are hard to kill at low levels!  I thought perhaps picking up a certain number of logs (killed tree) and taking them to an NPC or a certain spot like a river or stream to be used to build a bridge. Once you bring enough you can cross and get to a special object or on with a quest or something.   And I think those butterflys might be a gift to a lady NPC :)

       
    • David Kiser

      David Kiser - 2004-12-26

      Dynamic ones would be the problem, I think the way you laid out sounds good for a static quest system.  The factory approach makes it easy to put in modular content such as that, so adding new ones after the system in place would be a breeze.

      For dynamic quests, i'd start with building a couple of random arrays of actions/creatures/rewards and play mix and match, using a scaling algorithm to keep it balanced and/or level compatible with the character (dont want someone paying you 1000 gold to kill a lvl 1 monster), also you dont want a lvl 1 char. getting a quest to kill a level 30 monster.  I think a quest specific experience system/rewards would be cool too that would give the player oppurtunites that would only be availble through performing quests.  (for instance, after amassing a certain amount of quest exp a blacksmith might offer to upgrade his weapon, armor, or train in a specility skill).  This would induce folks to doing the random quests a bit more as it would have more benefits than a random item/money.  Might pay to investigate making the character object a bit more complex to incorporate some invisible quanities like fame, good/evil stat (based on if they took and completed good/bad jobs) , etc, then have reactions based on those.

      Anyways, I'm going way farther than discussing the quest system, just a few ideas.

       
      • Mike Anderson

        Mike Anderson - 2004-12-27

        These are all very good ideas, and absolutely relevent to the quest system!

        I agree that keeping a well-balanced game is crucial, and it's good to have as many ideas of possible around this. We also want people to actively hunt for good quests, so I also agree that giving unusual or valuable rewards is a good way to keep this interest. In fact, you could even get players doing quests for trivial rewards in order to gain the chance of a really good quest later....

        Regarding scaling, I am hoping that we can use monster level as an automatic scaling tool, e.g. hero level is a manageable monster, hero level+4 is a tricky monster, hero level+8 is a hard monster etc. The same should apply for items/quest rewards. I've tried to assign level values with this in mind, though it's going to need a fair bit of playtesting before it finally balances out ;-)

         
    • TubbyTunes

      TubbyTunes - 2005-01-02

      Is It Factory? I'm reading Orilleys "Heads First Design Patterns" What we want sounds like Ititorator and composite methods. Chapter 9.
      My other book "Refactoring to Pattern" suggest not to go further unless the classes are hetrogenous rather than homogenious. Just a thought. I'm still learning this stuff.

       
    • rick blaine

      rick blaine - 2005-02-13

      This was in danger of falling off the second page, so I'm bumping it.

      I'm playing with the design of a map location (Karrain University) that will offer quests where successful completion some of the quests results in the opportunity to learn or improve a skill. 

      By the way, any progress on the quest engine?

       
    • Jick

      Jick - 2005-02-13

      Not to try to make things more complicated, but I think a good step to take prior to implementing a quest system would be to add some way to tell the user an absolute name for where they need to go. When the world map is first generated, I think each interactive location (a town, a dark tower, a goblin village) should be assigned a real name, such as "Darkburrow" for an underground cave or "Faeville" for a town. Its appropriate name could be generated by a simple call to a name generating class which has a few static arrays of developer-created names and combines them with a method. For instance,

      class RandomStringGenerator {
          static Random rnd;
          static String[] townFirst, townLast, /* More arrays for other namesets*/ ;
         
          static {
              rnd = new Random();
              // These names could also be retrieved from a file
              townFirst = new String[] { "Fae", "Stern", Sax, Lent };
              townLast = new String[] { "port", "ville", ton, town, mont };
              // More initialization of arrays
          }
         
          public String getRandomTownName() {
              return townFirst[rnd.nextInt(townFirst.length)] + townLast[rnd.nextInt(townLast.length)];
          }
      }

      If each Quest and sub quest (Quests contained within another Quest due to combining) could be accessed individually, we could allow a great deal of inter-quest information handling. Here's an example:

      Quest.getSubQuest(int level) could return a Quest object based on the int argument passed to it. The argument represents the level of the quest they'd like to get. Each time the hero completes a sub quest, their level for that particular quest-group increases and, thus, we can manage how far along the hero is per quest.

      The Hero class could contain a Map of all quests he has started and how far along he is. A public method Hero.getQuestLevel(Quest q) could return the int quest level mapped to the specific quest passed to it as an argument. If the Quest could not be found, it returns a 0.

      So, after that lengthy explanation, here's my code:

      Quest current = mainQuest.getSubQuest(Hero.getQuestLevel(mainQuest));
      Quest next = mainQuest.getSubQuest(Hero.getQuestLevel(mainQuest) + 1);
      String destination = current.getMapName();
      String currentTarget = current.getTargetName();
      String nextTarget = next.getTargetName();
      Game.message("The shady aristocrat tells you, \" Fantastic! Now go to " + destination + " and kill " + currentTarget + " and bring me its " + nextTarget + ".\""; 

      The code relies on the assumption that each Quest object contain exactly one target Thing.

      With dynamic names like this, every NPC and/or town the user interacts with could have a unique name.

      My transcription here of concept to text is rather vague and messy. If you don't understand something, ask me.

      So what do you all think? I just can't imagine a quest system based on the current unnamed model of towns and such. The player would get a lot of In a town, there is a man who holds a great sword. Bring it to me.

      Jick

       
      • Mike Anderson

        Mike Anderson - 2005-04-01

        I think this is the right approach - with the proviso that we probably want to use a slightly more structured naming system behind the scenes.

        The current map naming system looks like:
        [mapname]:[level]:[instance]

        e.g. "town:1:27" is the first (and only) map of the 27th town that you have visited.

        We could augment this with the real names, i.e. the internal name would be "town:1:27" where the displayed name would be "Martlock Peak" or something like that.

        Tricky question is whether we want to delay the map generation for the quest location until the map is actually visited.

        Advantage is that you can assign the name, add quest items/monsters etc. immediately and store references to them.

        Disadvantage is that it will eat memory if not visited (and some quest locations could be very large.....)

         
    • Peter Mularien

      Peter Mularien - 2005-04-01

      What's going on with the quest system? How can we all help?

       
    • Mike Anderson

      Mike Anderson - 2005-04-01

      I'm hoping to get some time to write the base code this weekend with an example Quest type/quest factory. It probably requires a full day's work, which is always difficult to schedule :-)

      After that, it will be a case of developing other Quest types along the same lines. Should be quite interesting work - we'll probably have to put "hooks" in various parts of the engine to ensure that e.g. Quest completion conditions are detected, plus *lots* of unit tests etc.

       
    • Mike Anderson

      Mike Anderson - 2005-04-04

      First iteration of the quest system has now been committed.

      Implementation all in Quest.java, comments and/or improvements welcome.

       
    • Buddha Buddy

      Buddha Buddy - 2005-05-16

      I'm going to ramble a bit, so please be patient with me...

      I'm don't really care much for MMORPG games. I play games to relax, not to have to learn some skill like tailoring so I can spend hours doing routine stuff to make enough money to buy equipment to actually PLAY the game...

      However, while visiting a friend this weekend, I had a chance to play Worlds of Warcraft, which had the most enjoyable quest system I've ever seen, bar none!

      1. Quests have levels, so you know exactly how difficult it is the moment you get it.
      2. The quest names are color-coded (green, yellow, red, grey) against your current level in your accepted quest list, and you get more XP if you go after non-green quests. I didn't really notice the range, but it was something like <= current level+1 was green, <= current level+3 was yellow, <= current level + 5 was red, and <= current level+7 was grey.
      3. When you receive a quest, you are told exactly what the reward is, and in many cases, it was a choice of one of two items.
      4. When you clicked on a quest in the quest list, you saw the exact text of the original quest conversation, so you never had to bother with writing down stuff (another thing I HATE in a computer game), and it listed what the requirement was, how much of the requirement you had completed (3 of 6 plains strider claws), who you needed to report to in order to get the reward, and what town they were in or near.
      5. If a character has a quest available, then there is an exclamation point above his head. It was grey if the quest level requirement (different than the quest level itself) was higher than your current level, or yellow if it would be offered to you, so you always knew who offered quests.
      6. If a character was the TARGET of a quest (you needed to deliver something to them, or even kill them) then there was a question mark above their head. It was grey if you hadn't completed the quest yet, or yellow if you had and you just needed to talk to them to finish the quest.
      7. This is what really made my day. If a character was the target of a completed quest (had a yellow question mark above their head), then a symbol appeared on the "radar" map once the character was in your perception range, whether they were in your line of sight or not! No more of the stupid "OK, which of the two dozen moblie goblins do I need to talk to so I can complete this quest and get my gold" crap! I HATE that!

      When you start a new character, the first thing you see is a character with a gold exclimation point above his head. When you talk to him, he gives you a message to deliver to someone who is just inside a building not very far away, so you see the symbol on the map immediately. You deliver the note, and BAM! You just completed your first quest and gotten XP, and immediately knew how the quest system worked!

      Now, I'm not trying to say that all of this should be shoe-horned into Tyrant. Some of it probably wouldn't make much sense in a game like Tyrant.

      I'm positive that some people would HATE the idea of all the quests being so easy to find, since I remember someone saying in a post once that you might have to chat with the same person several times before they would feel "comfortable" enough with you to tell you their quest. For me, though, the more difficult you make it to find and complete quests, the more annoying you've made your game.

      And the most annoying thing of all is that I don't have time to work on any of this myself. Between work hitting a very busy period and my not-quite-two-year-old, I have very little of anything resembling free time, and I've already picked out a Tyrant pet-project to work on...

      I know you love the BaseObject/Thing design, Mike, but it DRIVES ME NUTS that there are no compile-time type checks and that everything is a String property in a lookup table. My save games are half a meg and take 5-10 seconds to save/load, and the game is still relatively small! As a 10+ year Java programmer, the non-OO design gives me the willies! :-) I'm playing around with some ideas to make it OO and still be as flexible as it is now. At the rate THIS is going, I'm not going to be able to play with the quest system for quite a while.

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks