[CF-Devel] More Lore

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

Ok, I hope you don't get the idea that I'm trying to escalate scope every
message, I am primarily concerned with establishing a good and useful
repository of lore.  How this is used in the game is of interest at the
moment only in that it is properly supported by the data format.
However since people are suggesting different things, I am collecting
further information on how to proceed.  I do propose to do any of the
necessary remaining work to implement this since the lore field has been
incorporated into the arches.  Any code needed to collect the lore I'll
write (initially in Python, but I will translate to Perl if I have to).  I
will of course leave a lot of room for writing the actual lore however, and
any code that uses this data.  I don't believe any further changes to the
server code is necessary unless it is decided to embed a lore tag in the map
data format (hey, I might even be able to manage that myself too.) I will
try to be specific to the point of annoyance on this.  Anyway here is how I
thought I was seeing it working.

There are two types of lore on the table here, generic lore in the arches,
and specific lore in the maps.  I'll start with the basic proposal: generic
lore in the arches.  Generic lore is such that it applies to a class of
objects like a monster or a ability or whatever.  This will never show up in
a map.

Lore in the arches is entirely contained in between the lore <-> endlore
tags.
It should look like this:

arch mogo
name mogo
[...] all usual arch info
lore
@chance 3:
A mogo is found useful for foobar.
@ chance1:
Some mogo are cursed with juju.
endlore
end

This information is collected by script into a file that looks like:

<Lorefile>
     <lore>
    <name> mogo</name>
    <item chance='3'>A mogo is found useful for foobar.</item>
    <item chance='1'>Some mogo are cursed with juju.</item>
    </lore>
[...]
</Lorefile>

I did plan to use XML format, but if this is a problem, it could just as
easily be written like so:

name mogo
    chance 3:
        A mogo is found useful for foobar
    chance 1:
        Some mogo are cursed with juju.
end


Then this file is used to generate anything from books to NPC messages.  The
rank is calculated within that item entry(and not within all lore), so the
chance in this case of seeing the first line is three in 4 and the second
line is one in four.  The name is pulled from the arch name (I had planned
on collecting by name so that if there were a couple of arches with the same
name they would all be one entry) and while it does not have to be, there
needs to be some way to seperate the groups and this seemed simplest.  It
also provides a convienent handle.

That's it for general lore.

Map lore is specific, when making a map, if the mapmaker *changes* the lore
of an arch they place on the map, it is going to get written to the map (try
it...).  So this should be collected too since it is there anyway and is
just wasted if not used.  For specific lore such as this however there you
might not want to store it as simply as the generic lore, but you do want it
to be compatible so that if someone writes a cool book generator or robot or
some such based on this format it will work across the board.
If you place a dwarf named Ernie in Boomtown who holds the sacred cup of
Umluk, and you want this to show up in the lore of the land (libraries,
oracles whatever), you would want something like this:

arch dwarf
name Ernie
[...]
lore
@chance20:
The sages of Umluk were known have a passion for orcknuckle and would often
nip off to the redlight district of Boomtown for a quick game or three.
@chance5:
The finest 'knucle player in Boomtown is Ernie the Dwarf.
@chance1:
The word on the street is that Ernie the Dwarf won a sacred artifact from
the sages of Umluk in a game of orcknuckle.
endlore
end

...of course the cup would have it's own lore mentioning Umluk and sages and
such.  The point being if ever the cup gets moved and Ernie gets the axe due
to low ratings - the lore manages itself.

Well it is pretty stupid to collect this under Ernie since there could be 40
Ernie's with all the gnolls, demons, dragons and other NPC's all around the
world.  Also someone may customize the lore but not the name.  Also there is
a whole bunch of this type of lore that would be more related to the map
itself (like cities or legends or the like) than a specific arch so how do
you deal with that?  I did suggest a lore field in the map header but this
was not well regarded at first, so I proposed to extend what was already
occuring and make a special arch just for map lore where by it provides a
name field and a lore field and could be collected by the same script as
everything else.
If it is more acceptable again to put a lore field in the map header (only
need to instruct the server to ignore it is all...) then I suppose there is
no real need for a maplore arch (although any arch on a map could be used as
a maplore arch really...).

<digression>Well for a while I thought if you are collecting information
anyway, you can grab the lore, check the map arch for vitals such as level,
hp, resistances, abilities or whatever.  Since this type if data is in the
current book code it would be nice to incorporate it as well.  If these were
not in the map because they were not modified, you could jump to the
archetypes file and read the parent arch from there to get this info.  Since
this is a script to generate metadata  into a repository, it can be as slow
as cheese soup.</digression>

Of course this is a whole pain in the butt because as was mentioned item
type influences the meaning of these fields and it is much simpler and more
nice to do this as suggested in the lore field itself.

All issues with using fields for name, location, level, distance from
Arizona or alternate key words or whatever anyone needs in the future can be
handled as Mark suggested.

lore
@ <rank> <region> <true/false> <key word> <what ever else>:
put your message here
endlore

So in the case of Ernie the Dwarf, you would now have:

lore
@ chance "20", region "Boomtown", key "rumour", true:
The sages of Umluk were known have a passion for orcknuckle and would often
nip off to the redlight district of Boomtown for a quick game or three.
[...]
endlore

And you can dump a lot of lines in the lore field of the map itself.
<speculation>I do wonder however how would you seperate the different
subjects  for weighting purposes since having many entries in one lore field
would also weight the messages.  Also unless a name is put in the lore field
there won't be one.  That may not be an issue I suppose.  Also things like
name and location generally would apply to all the lore in that block so
adding it to each delimiter would be a pain and bloat up the arches,
especially if there are 10 different items.</speculation>

The end result I am picturing something like this:

<Lorefile>
     <lore>
        <name> mogo</name>
        <item chance='3'>A mogo is found useful for foobar.</item>
        <item chance='1'>Some mogo are cursed with juju.</item>
    </lore>
    <lore>
        <region>Boomtown</region>
        <keywords>rumour</keywords>
        <item chance="20">The sages of Umluk were known have a passion for
orcknuckle and would often nip off to the redlight district of Boomtown for
a quick game or three.</item>
        <item chance="5">The finest 'knucle player in Boomtown is Ernie the
Dwarf.</item>
        <item chance="1">The word on the street is that Ernie the Dwarf won
a sacred artifact from the sages of Umluk in a game of orcknuckle.</item>
        <true = 1/>
    </lore>
[...]
</Lorefile>

Then again it could written like this directly in the lore field right from
the start...

I don't really know what will be done with region, level, key word, or
true/false, but I can see it as being useful if a NPC robot was written that
answered three questions (keyword), or library code weighted location and
level or keyword (legend, rumor, recipe... whatever) when generating books,
or (more contraversial for reasons mentioned) NPCs in an area could be
assigned certain or key words (e.g. @@match Boomtown ) or what ever.
Taking a point from other discussions where I have given quick functional
examples and gotten totally misunderstood,  I have to make it clear here
that I am not proposing the above examples or advocating specific features
as stated, just saying what types of information may be useful in the lore
datatype and why it might theoretically at some point be used.
As long as it is consistant so that I don't have to rewrite 500 entries that
cannot be modified by script or it otherwise does not have to be totally
reworked for new futuristic data mining tactics two months from now, I'll be
alright.


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