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

[Mark Wedel]

Raphaël Quinet wrote:

>>   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).

  I'd probably say that the books about spellpaths are pretty much useless.

  They could perhaps be more interesting if they give more information - knowing 
the spellpaths isn't particularly interesting.

  Knowing what spells, with descriptions, damage, whatever could make things 
more interesting (spell abc looks really cool - I should find a copy).  But it 
seems that the general case for games is that information of the spells is 
pretty widely available, so that if you know a spell, you know about it.


>>   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.

  Yes, and this regionalization could even go just beyond surrounding dungeons - 
one could envision that some alchemy formula only appear in certain reasons, or 
make more specific information about the local government, etc.


>>   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).

  Yes - having a method for the client to request the information is fine. 
Arguably, the client doesn't even need to request it until the player actual 
goes to access the information.

  One issue with never removing cached data is having old/obsolete entries stick 
about.  Suppose a monster or object is renamed - there is no way for the client 
to know that, so it just has the old entry for the rest of time, which could 
eventually get annoying.

> 
>>   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.

  but even then, probably wouldn't be that long/bad to handle.


> 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.

  I'd think from a cleanliness standpoint, it should be done as a menu item.

  Otherwise, it is odd in two regards -

1) The client has to know to handle the book activate request in a special way - 
instead of sending the apply event to the server, it has to go and do whatever 
is needed to access the info.

2) The player probably has some expectation what happens when they apply an item 
in their inventory, and having a window or whatever pop up with all that info 
probably isn't it.


>>> - 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.

  Yes, having PNG maps would be nice.  Even for other stuff, it could be nice, 
like images of important people, gods, etc.