[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