[CF-Devel] More Lore

[crossfire-devel-admin at archives.real-time.com]

Todd Mitchell wrote:
>
     
      Ok, more thoughts on lore:
     
     >
     
     
     >
     
      For generic lore in the arches I believe it is established that it is 
     
     >
     
      sufficient to populate the lore <> endlore field with weighted values, e.g.
     
     >
     
     
     >
     
      arch orc
     
     >
     
      <..>
     
     >
     
      lore
     
     >
     
      @5 Orcs are the foul brethern to goblins.
     
     >
     
      @4 Dwarves and Orcs have a strong hatred of one another.
     
     >
     
      ...
     
     >
     
      endlore
     
     
  The @5 (or whatever) must be on its own line, followed by various lines of 
lore, and then perhaps another @whatever, etc.

  Reason for this:
1) it means you can have long lore descriptions without needing to have several 
hundred character long lines.

2) The meaning of the @ can get expanded more easily in the future, eg, @5 could 
become '@5 santo_dominion 3', or whatever else.  If the lore it describes is on 
the same line, it makes expansion more difficult, and parsing also more difficult.

>
     
     
     >
     
      Whereby the object name, level and other information could be grabbed 
     
     >
     
      from the arch if necessary too.
     
     
  I don't get that point.  Are you talking about embedding control sequences in 
the lore for this information? I otherwise don't see what that info would be 
used for.

  In any case, all the information the lore needs should be in the lore area. 
Don't presume that grabbing information from the arch will be easy or even 
possible in the code.  And I'd add that don't presume that the information in 
the arch is at all meaningful - for many monsters, the level of the monster may 
not be especially meaningful.


>
     
      If you customize a creature you need to 
     
     >
     
      grab this out of the maps however, e.g. if you make a special dragon, 
     
     >
     
      you can put in special lore, it is stored on the map.  This has to be 
     
     >
     
      picked up during the map lore collection however.  This would capture 
     
     >
     
      the arch name and name if the object had one (have to remember to check 
     
     >
     
      for no name...) but I don't know how stuff like level and such can be 
     
     >
     
      easily snagged with a script if it has not been changed (look up the 
     
     >
     
      arch?- yuck)
     
     
  I note you are going beyond how you had originally described the lore stuff. 
The original idea of lore was to more easily connect information about arches 
with the arch itself.  You're now talking about expanding this more and more 
beyond the original idea.

  And as said above, I fail to see why you need to care about level or object 
name information.  If relevant, it should be included in the lore information 
itself.


>
     
      For map and quest type information this is not going to work, some maps 
     
     >
     
      have nothing of interest, and some like the city maps have many 
     
     >
     
      many points of interest.  If you were to go with a header file, you 
     
     >
     
      would need to account for different topics.  Also this information can 
     
     >
     
      be more tricky to manage since it is more specific.  This is why I think 
     
     >
     
      a specific maplore arch object would be good in addition to the lore 
     
     >
     
      field.
     
     
I disagree on that point - if all the information is in the 'lore' field, as it 
should be, there is no reason you need multiple objects.  And I still have the 
concern that if you have a bunch of objects with lore on a map, that it will be 
very difficult to manage this information (need to figure what objects have 
lore, where they are on the map, and so on).


>
     
      The only thing is that both types of lore should follow the same data 
     
     >
     
      format, style guidelines (including truth and falsehood, weighting and 
     
     >
     
      level and key word information) and be accessable through the same 'lore 
     
     >
     
      engine', although not perhaps in the same way...
     
     
And I think the @ with sufficient fields is more than sufficient to do that, eg:

@ <level> <region> <true/false> <key word> <what ever else>

  I'm concerned about the keyword stuff however.  I'm presuming that this is 
supposed to mean that if I say 'orc' to an NPC, if it has any lore that has that 
as a keyword, it would respond.

  But this seems very random - that npc now needs to provide some clue as to 
what it knows about - if it is just a matter of randomly guessing what the npc 
knows about, that is completely useless.

  And at that level, why not just design proper NPC's with bits of information. 
  No matter what you do, properly designed NPC's will still be better than 
random lore.

  I will also note that in the original discussion of lore that the idea was for 
it to show up in things like books or other static sources, and not dynamic 
things like NPC's.

  Having lore show up in NPC's also requires the need to have some flag to say 
'generate random messages from lore for this NPC'.  You don't want to do this by 
default - first because it won't work well, but second, because you really don't 
want to this for every monster that could be generated - a fairly costly 
operation to do for something that is likely to be killed.





_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel