[crossfire] Quests, continued

[Mark Wedel]

Nicolas Weeger wrote:

>
     
      I was thinking of:
     
     >
     
      * create a new either 'quest' archetype, or special force, for
     
     >
     
      quests (right now i use forces, will probably keep that)
     
     >
     
      * use that to link items to quests. So an item could actually
     
     >
     
      be part of multiple quests. It's then just a matter of adding
     
     >
     
      force to item's inventory - editor lets do that, and maybe
     
     >
     
      we'll have a nice interface to manage quests.
     
     
  That can work, as long as the item in question doesn't normally have an 
inventory that is used.

  For example, such a system would not work if you wanted to make a rod of 
restoration as part of a quest, because it already has a spell object in the 
inventory.

  but it is true that you do need to have someway to denote what quest an item 
belongs to.


>
     
      Then it could be simple, when opening the chest, to check for
     
     >
     
      one such force in items in chest - if there's a force, and
     
     >
     
      player doesn't have it, remove affected item.
     
     
  Mmm - this could work better the opposite way - have the force contain the 
item in question - if matches player, then remove object from force and insert 
it normally, if not, just remove the force as well as its contents.


>
     
      I would say:
     
     >
     
      * quest items burn as everything else, unless mapmaker made it
     
     >
     
      indestructible. After all, not different than existing quest
     
     >
     
      items!
     
     
  But for all items, it isn't a 100% sure thing that items get destroyed - 
pretty much all items have some probability of it happening or not.

>
     
      * quests should be party-aware. So if a party player is doing
     
     >
     
      a quest, and another party player not doing the quest opens
     
     >
     
      the chest, the quest item does appear and maybe quest-doing
     
     >
     
      player is warned so he can tell other player 'gimme that item
     
     >
     
      plz'.
     
     
  yeah, perhaps.

>
     
      * if two unrelated players play in same map, and one not doing
     
     >
     
      the quest opens the chest, item doesn't show up. Let's just
     
     >
     
      argue that the player forced the chest open and destroyed the
     
     >
     
      item by being uncareful :)
     
     >
     
      * or we could give the item anyway - this way quest doing
     
     >
     
      player could get item from another player
     
     
  To me, this seems the more logical approach.  If you're not doing a quest, 
finding that silver mirror is probably meaningless to you, and that is how it 
would be in real life.  If you are doing the quest, you'd be informed that the 
silver mirror needs to be returned to xyz.

  Sure, it does mean other players could fetch quest items for others.  But that 
isn't very far removed from 'killing all monsters so player on quest can come in 
and open the chest'.

  After all, the person that wants the silver mirror doesn't care how it is 
returned - if it passes through 10 hands, doesn't make a difference to them.

  If player fetching it is important, could always add one of the proximity 
checkers on the map to make sure the player at least visits the map.

  Which leads to an interesting question - is it possible to set bit states on 
the quest status flag.

  I'd imagine you could have a thing like 'go here, get item X, kill y'.  And 
you'd want to do something like |4 for the go here, |8 for get item, and |16 for 
kill y, and then check for 28 in the state flag.

  Granted, this could be done by three seperate quests, or by enforcing order 
(stage 1 sets state to 4, and only if state is 4 will get X set it to 5, and 
only if 5 will kill y set it to 6, etc).

  Perhaps an easier to see example would be 'deliver these 5 messages to ...' 
type of thing.