[crossfire] Dialog modification

[Mark Wedel]

Nicolas Weeger wrote:
> Hello.
> 
> I'd like to improve NPC discussion with the following system:
> * NPC displays a text
> * the player has a list of available replies
> * choosing one reply leads to another text
> * the player can also enter an arbitrary text

  Sounds good to me (something I've been wanting for a while).

  At its simplest, this is really just a map update and a little client support. 
  My quick thoughts:

1) For all the msg/endmsg, add a tag for the replies (like the font, bold, 
underline, etc that are currently supported in messages).  Old clients should 
just ignore the tags, and smart clients can display them appropriately.

  I'd think it wouldn't be that hard to write a script to update all the maps - 
it just has to look at the msg field, look at any @match lines, and then insert 
the tags into the actual text that the NPC says.

2) The client displays that tag in some special way - something like a hyperlink 
may make the most sense.  If the player clicks on the link, the client can 
easily enough see what word it was, and then just send a 'say ...' to the 
server.  If for whatever reason, the client can not easily support clicking on 
the word, just display it in bold or underline would give player enough of a 
clue and they could manually put in the say.

  Now you didn't go into much detail, so I'm not sure if you plan a large revamp 
of the conversation system.  There is already the CFDialog plugin which allows 
more complex conversations - I'm not sure in how many places it is used - it 
would seem any of those would need to be hand updated.

> 
> The three first things make the dialog much simpler for players. The fourth is 
> to "open" some text only if the player uses the right keywords.

  I think the fourth is also needed because some NPCs have multiple paths of 
conversation, so if you go down one path, with various follow up questions, you 
want to be able to basically go back and go down the other path.

  If what I describe above is used (or something similar), then there is no 
problem with the player going back to a previous message and clicking on some 
other word to go down that path.  However, if something different is planned and 
the replies are more in scripted fashion, that perhaps get trickier.

  For example, in my description, a conversation may be like:

NPC: I've fought a lot of *goblins* and *orcs* in my time.
(player clicks on goblins word, and client send 'say goblins' to server)
NPC: goblins are fairly easy to *kill*
<and so on>.  And player could go back and click on orcs and things would work.

  But what looks nicer to the player is something like:
NPC: I've fought a lot of goblins and orcs in my time:
-> Tell me more about orcs.
-> Tell me more about goblins
(the -> is to indicate a reply).  Player clicks on the goblins line:
NPC: goblins are fairly easy to kill.
-> How do you kill goblins?

  This second method is more complicated, but in some ways also nicer, because 
many NPC's have different words that get the same message, so highlighting all 
of them could be sort of ugly.

  But this second method is a bit more complicated - those reply messages have 
to be coded somehow, and in that second case, unclear how easy it would be (or 
if even proper) if player went back and clicked on a reply to a previous message.

  In this second case, it could perhaps be done with tags also, something like:
<reply>Tell me more about orcs</reply><say>orcs</orcs>
<reply>Tell me more about goblins</reply><say>goblins</say>

  Where the reply is a tag used to prompt the players, and the <say> tag is used 
to tell the client what word to send back to the server.  What makes this 
perhaps slightly more complicated is how easily it is for the different clients 
to store the say data for the previous messages away, so player can back up.

  A nice thing about this second method is that it allows for what seems to be 
more complicated conversations without needing to use the CFDialog, because the 
say words could sort of act like variables.  For example:

<msg>
@match *
Are you interested in getting treasure?
<reply>Yes - I really like treasure</reply><say>yes_treasure</say>
@match yes_treasure
Are you interested in killing monsters?
<reply>Yes - I really like to kill monsters</reply><say>yes_monster</say>
@match yes_monsters
....

  Of course, with the actual replies in place, the string of yes replies is not 
needed, so in most all cases, that wouldn't really be needed.