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.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
