[crossfire] proposal: quest tracking

[tchize]

Nice project, overall

Just a short(#) note on the way to track quests.
IMHO the actual way to track things on player (using forces and other 
invisible objects in inventory) has it's use only when you need to check them 
against detectors (check-inv).
This way of handling things has a major problem, i think, in terms of code 
readability. The main reason it was saved in the inventory is becasue the 
player is saved as an object and everything in crossfire is object. However, 
there are already specific fields for the player which are saved outside of 
the object saving code. 

I think the markers (at least new ones, like is the case for quest) should 
have this special behaviour too. We should maintain a simple list in player 
having the form 'key=value' with key and value as a string. If we used more 
of such marker in future (am working currently on a system to have npcs 
'memorize' what they already said to a player and change their dialog 
according to markers stored in player) we have a problem because scanning the 
inventory to 'search for a keyed item' is quite slow. We can not keep the 
list ordered, and this list contain not only markers but also all the player 
inventory. And we all know players can have lot's of thing in their 
inventory.

It should be quite easy to have check-inv code additionnaly checks this list 
for values which key correspond to an existing key.
For the saving, we could save the player markers like this:

marker quest.scorn.assasinate_gothwalte
got the knive
endmarker
marker scorn.title
knight of scorn
endmarker
marker quest.scorn.terrys_farm.guuhs_head
pending
endmarker
marker quest.someQuest.someSpecialValue
some
multilines
value
endmarker

The code could then implements functions like

char* getPlayerMarkerString(player,key);
int getPlayerMarkerInt(player,key);
int getPlayerMarkerBoolean(player,key);
void setPlayerMarkerString(player,key,value);
void setPlayerMarkerInt(player,key,value);
void setPlayerMarkerBoolean(player,key,value);

So, to resume:
*Positive points
  - marker list easier to manage
  - can be checked agains existence/value with check-inv
  - more marker intensive things like conditional dialogs with npcs easier to 
manage and won't risk to become bottlenecks
  - an admin opening player file can easily see all player markers and their 
value
  - easier to debug (i remember player losing the 'knight of scorn' tag in the 
past because the marker had a time out)
  - using a dot based marker like in example would help regroup infos from a 
same quest
*Negative points
 - Need to adjust check_inv functions
 - May the coder implementing it will have some compatibilities nightmares 
(WHO said tchize? sending virtual aspros to Ryo)


Now, the rest of suggestion. I like the idea to have all objects' message 
conditionned by the quest parameter. I like the suggestion of mwedel too, and 
i think it makes lots of sense. But just one thing. Why use a tag named 
%quest while a more generic tag named %marker would be more usefull and could 
be made to check the existence of a given marker, not only quest markers.

And for the quests hints, maybe have an other list in player for quest,
aka and array of 'quest entries' saved like this:
quest guuhs_head done
questmsg guuhs_head.title 
A troll at terry's farm
endquestmsg
questmsg guuhs_head.farmer
The farmer tells you about the raiders who have occupied his farm, and begs 
you to help, telling you to take the key in his kitchen and free them from 
the bandits.
endquestmsg
questmsg guuhs_head.
You have killed the leader of the brigands, and will doubtless be rewarded 
handsomely for your valour
endquestmsg
questmsg guuhs_head
You have saved the farmers etc etc
endquestmsg

the 
quest guuhs_head done 
tell server there is a quest labeled guuhs_head and which is finished
then all questmsg starting with guuhs_head will be considered as hints which 
could be shown by the client in som logbook


Anyway, whichever implementation you choose, i approve a system where quest 
will be more formalized.

Cya, going back to some protocol modifications. (Ryo, i just reminded, i need 
those aspros for tonight)


(#)Just kidding, this is NOT a short note:)

Le Jeudi 03 Mars 2005 11:38, nicolas.weeger a écrit :
Hi.

Nice idea!

I'd suggest doing quest tracking like markers, though: with creators,
 detector and modifiers objects. So you can forbid a player entering some
 place if s/he isn't doing the quest, and so on - like a non transferable
 item, but invisible.

This way you can make the player start a quest by saying something to an NPC,
 then end the quest when entering a room, or killing a monster (make it drop
 the quest modifier!), and so on.

The only point is, how would you track the quest information the player has?
 IE if s/he got 3 hints, do we store the hints in the player as hidden
 fields? Of course they can be removed later on, when quest is completed.

As for the say command modified, sounds like a nice idea. This way it's more
 flexible what an NPC can say depending on quest the player is doing.

Anyone willing to work on that? I could do it, if no one wants :)

Ryo who is kind of back on the net, and may just have time to work on CF some
 more.

Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)

-- 
--
Tchize (David Delbecq)
     
     tchize at myrealbox.com
     
     
Public PGP KEY FINGERPRINT:
    F4BC EF69 54CC F2B5 4621  8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
    
     
     http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
     
     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 
     
     http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050303/8432718a/attachment.pgp