[crossfire] Proposal for better in-game information: client-side "player books"

[Raphaël Quinet]

On Mon, 14 Aug 2006 22:21:38 -0700, Mark Wedel <mwedel at sonic.net> wrote:
>   id being the archetype probably makes the most sense.  If you make it numeric, 
> it would have to be some sort of hash I'd think so that it is consistent, and 
> then there is always the danger that something new is added causing the hash 
> conflict, resulting in the hash changing anyways.

In most cases, using the archetype as <id> is the best choice.  But I
would also like to be able to document some artifacts, not only the
archetypes.  For the artifacts, the best choice would probably be
"archetype name + title", which should be unique.

>   Alternatively, the number itself could be in the archetype, but that would 
> seem to be full of problems - duplicate numbers, etc.
> 
>   Given this content isn't sent very often, not sure if using the longer 
> archetype name would be a problem.

Right.  Even if the string is a bit longer when the title is included,
that should still be acceptable for something that is not sent often.

>   Spells:
> As of now, you can't learn a spell unless you are sufficient level to cast it 
> (DM's could teach you spell without that restriction, but that is a bit of an 
> edge case).  Now it is possible you learned a spell, died, lost some levels, but 
> then in that case, you still knew all the attributes at once.  While it is 
> reasonable to say that since you can't cast the spell, you can't remember the 
> details - the problem is that could then lead to outside game notetaking on what 
> you did know.

Yes, I was thinking specifically of the case of a player losing levels
after a painful death.  And I think that it is better to let the
player keep the information, but simply add a note saying something
like: "you are currently unable to cast that spell".

>   For the same reason, I think it is good to give full information for the 
> spells the player knows.  Some of it could be figured out empirically - I'm 
> denied healing, and can't cast that spell, thus it must be in the healing path, 
> etc.  But some is playability - if that information is really needed, and isn't 
> being provided, I'll just go elsewhere for the information (spoiler, whatever).

In that case, there is really no reason to keep the random books about
spellpaths.  If learning a spell is enough to know which path it
belongs to and if the table of spells can be sorted by path, then the
books about spellpaths are almost useless.  The only hint that they
could still provide is the name of some other spells belonging to the
same path and that are not known yet by the player.  However, this
information is not very important and some of the spells may not even
be available at all (e.g., special prayers).

>   Storing information:  It should be stored in the archetype it describes - the 
> addition of files in the lib directory to describe archetype is the wrong way to 
> go (if anything, we are trying to move away from that, with things like the .trs 
> file).

Right.  When I mentioned a file in the lib directory, I was thinking
about where the server can find this information.  But it could of
course be collected from the archetypes, just like the treasure
lists.

>   There is the lore/endlore fields right now which was envisioned to hold 
> information on various things that would then go into books.  I'd suggest that 
> could be used, with perhaps defined tags for different fields, eg:
> abilities: ...
> desc: ....
> other: ....
> 
>   and so on.

Good idea.  Using the "lore" attribute is probably the best solution.

>   There may still need to be some information in the lib directory for data that 
> isn't directly related to any archetype (rumors of a dungeon, etc).  One thought 
> on that is that the file should probably be extended to have region clauses - it 
> doesn't make much sense to be hearing about information of a dungeon near scorn 
> if you're in wolfsburg.  By localizing the messages, it then means when in 
> scorn, you'd get lots of information about what is in and about scorn, etc.

Also a good idea.  This would encourage the players to visit other
regions and collect their random books.  The region-specific
information could even be part of the maps module rather than the
server module and then collected and stored into a file in the lib
directory.

> > - If the player already knows some piece of information, it would be
> >   nice to leave the corresponding page(s) in the game instead of
> >   taking it away.  This is how spell books and skill scrolls work
> >   today.  How should the server know if the page(s) should be removed
> >   or not?  Should the server keep a list of all things that have
> >   already be sent to the client?
> 
>   I might have missed it further above, but this note here suggests that this 
> information in cached client information?

Yes, my idea was to cache this information on the client side in order
to allow the player to browse through it offline.  I would like to
have enough information in these player books so that the Crossfire
spoiler and handbook would not be necessary anymore.  And it is useful
to be able to read this information offline, without playing.

The client could provide its own interface for reading this special
book (e.g., a large window with various tabs for the different kinds
of information: monsters, spells, etc.) but I think that it would also
be useful to be able to read it in a standard HTML browser, directly
from files generated and stored on disk by the client.  The HTML view
could use nice CSS and images to make the information more attractive.

Offering the HTML output would also make it easier for the clients:
some clients could implement the book browser in their own interface
but some other clients could simply rely on an external web browser
and would not have to worry about displaying text and images from all
these messages.  So when a player using such a client gets a new piece
of information and wants to read it, the client would simply trigger
some external web browser or help browser, as this is done in other
programs to display online docs.

>   If so, I'm not sure that is a good approach or not - there is no guarantee 
> that players will be on the same computer, and thus would lose that information 
> (currently, the only thing the client really stores locally is the user 
> preferences).  I'd say that would be unexpected by most players.  And if done, 
> then such caching would have be be segregated based on the server it came from, 
> since different might not agree on all the data.
> 
>   The client caching the data would also infer that this knowledge is really 
> player knowledge, so if you played a bit and made a new character, that first 
> level character would have a lot of knowledge.  Maybe that isn't bad - not 100% 
> sure.

Sure, these are pros and cons to the client caching option.  I would
like to have it because I am not permanently online and I would enjoy
being able to read some of the hints and other information collected
by my character even if I am not connected anymore.

One way to avoid problems when players use multiple computers or
connect to multiple servers would be to do a cache synchronization
when the player (re)connects.  If the server keeps track of what each
character knows then it could send this list to the client, which
would then remove some of the messages from its cache and request the
missing ones from the server.  I think that the general information
about the religions, quests and other random messages should never be
removed from the cache.  Maybe this could even be the case for the
monsters and artifacts.  The only categories that the (non-cheating)
client should remove from its cache are the list of spells and all
formulae (alchemy).

>   I do say I think it would be nice from a game perspective to actually know 
> what information the character has learned - alchemy could require you know the 
> recipe, quests/npcs could give pieces of missing information, etc.

Yes.  The drawback is that the server would have to keep track of all
that on a per-character basis and that could be a rather long list.

> > - These special books could be represented as objects in the players'
> >   inventory or they could be "out of the game" with a specific client
> >   interface to access them (just like the list of skills or spells can
> >   be obtained without using an object).
> 
>   I'd think that if they are in game, then if you applied one, there would be 
> too much information pretty quickly to reasonable read/parse, so I think some 
> other interface is needed.

Well, of course I never intended these objects to display their
information in the normal info window.  What I had in mind is that if
these books are shown in the player's inventory, applying them would
open the new book browser (new interface with images, etc.) or maybe
even trigger an external web browser.  Just like some programs do when
you press F1 to get help.  Showing the special book as an item in the
inventory would simply provide another way to start the book browser
(the other way being via the client menus) and maybe also a way to add
weight to the player if the book contains a lot of information.

>   It could really be seen as an interface to the characters memory.

Yes, that's a good way to describe it.  So maybe it does not need to
be shown in the inventory.

> > - All messages described above can be sent in plain text (maybe with a
> >   bit of markup for cross-references), including the images if they
> >   refer to existing faces.  However, if we find an artist who has a
> >   lot of spare time to spend on crossfire, it may be possible to
> >   enhance the messages with custom images to be included in the HTML
> >   rendering of the player book.  How should the images be sent to the
> >   client in this case?  As special faces or as part of the messages?
> 
>   There isn't any reason that the image couldn't be added in the archetypes and 
> sent in the normal way (I'm not even sure if there is any real maximum size if 
> it is just an image not displayed on the map).  Sending it as part of the 
> message would seem ugly.

Large images could be useful in some messages.  For example, we have
some random messages containing ASCII art maps.  Replacing them by a
nice PNG image would be an improvement.  Especially because the ASCII
art maps do not work anymore with a proportional font.

Thanks for the feedback on this proposal.  It is not for the near future
anyway, but maybe some bits of it could be considered for 2.x or 3.x?

-Raphaël