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

Mark Wedel mwedel at sonic.net
Tue Aug 15 00:21:38 CDT 2006


  Some quick thoughts:

  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.

  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.

  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.

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

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

  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.

  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.

> Open questions
> --------------
> - When a player reads a book or scroll in the game, the information is
>   taken from it and put into the "player book".  Should the book or
>   scroll disappear or should it be replaced by an empty book (from
>   which the pages have been removed)?

  either would be fine - it could be argued that since the pages are removed, 
the book is effectively destroyed - it hasn't been erased after all.

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

  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.

  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.

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

> - If these special books appear in the inventory, they could slowly
>   gain weight as more pages are added to them.  Is this a good idea?
>   And in that case, how could the player avoid gaining too much
>   weight, especially if the character is weak?

  And what happens if a player drops it?  If they no longer have their travel 
book, what happens if they find one of those readables?  Can someone else then 
pick up that dropped book?

  I'd generally say like above, this should be hidden information - it should be 
seen as a convenience for players, and with that, some better interface to 
navigate the information.

  If there are disadvantages to the new system, you'll either get people not 
using it, and/or just copying the information from crossfire to an editor they 
have and store the information there.

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


> - Should there be a way for the player to add her own notes to any
>   page?  Or could there be a special part of the book or a separate
>   book (notepad) in which the player could add some notes?

  It'd probably be nice to have some method for the player to add notes - I'd 
say for the different attributes, each having a potential 'player notes' section.

  I'd expect that there will be gaps in information.  A player may find a really 
good attack for a monster that isn't recorded with the info we provide - they 
may want to record it for the next time.

  Or maybe record location of dungeons, best places to sell stuff, etc.  Once 
again, make the game more convenient for the player.


> - It would be nice to allow the player to read all that stuff outside
>   the game.  This could be done from the client itself or from a web
>   browser if the information is availble in HTML format.  Should
>   everything be stored as static HTML pages overwritten by the client
>   after each update?  Or is it better to add a tiny web server to the
>   client and let it generate the pages on-the-fly?

  Not sure how much need there is to store/access this outside the game.  If 
stored as a file, the location has to be easily accessible.

  Adding a mini webserver to the client doesn't seem like the right approach - 
too many problems with that - it'd have to run on a non standard port (need root 
to run on the standard port), more issues to support it, etc.

  I think it might be cleanest to add an export option in the client that 
exports this data to a location the player specifies.

> - The "player book" could be stored per character or per client/player
>   (shared between characters created by the same player).  Although
>   the purist way to do it would be to store it per character, it could
>   also be argued that the player knows the information anyway, so why
>   not let it be shared between all her characters?

  I'd say player, for reasons I state above.

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





More information about the crossfire mailing list