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

[Raphaël Quinet]

Here is a rather long proposal for improving the information available
to the players.  This is something that I had in mind since quite a
while and I originally did not want to talk about until I had some
time to work on it.  But Lauwenmark/gros asked me nicely to describe
what I had in mind. :-)  And it looks like I will not have the time to
work on this in the near future, so I'd better do a brain dump now in
case someone is interested...

Introduction
------------
The basic idea is to replace most of the books, scrolls and other
readable stuff in the game by permanent "player books" that collect
the information automatically and make it available to the player at
any time.  This information would become richer as the player explores
the crossfire world.  These books would be a client-side feature
accessible at any time and they could even be made available outside
the game as a set of player-specific HTML pages.

These "player books" would more or less replace the Crossfire Spoiler:
they would eventually contain the same information in a format that is
easily browsable.  But the contents would be provided gradually by the
game itself instead of being available all at once from a web site or
from one big file.

These books would also replace the list of spells that can be
displayed by most clients.  They would give an overview of the spells
and prayers that are known by the player, including their description
and an indication about which ones are denied/repelled/atuned
(probably laid out as in the gtk2 client, with options for sorting).

In the current game, there is a difference in the way spellbooks or
skill scrolls are handled compared to other types of books: a
spellbook disappears if the player learns a new spell or prayer from
it.  But other books or cards do not vanish after being read.  With
this proposal, all books related to skills, spells, spell paths,
monsters, religions, artifacts and quests would be handled in the same
way: they would be removed from the game as if the player had taken
the pages and added them to her own book.  Note: this only applies to
the generic random books - other readable items such as signs, cards
and unique books that are included in maps will not be "consumed" by
the player.

Additions to the client-server protocol
---------------------------------------
The new information will probably have to be sent to the client using
a new S->C command similar to "drawextinfo" (it would also include
some information that is currently sent by "addspell" or "updspell").
Like for most new commands, the client could indicate that it supports
it by using a new "setup" option.  The new command could be called
"addinfo" or "storeinfo" or something similar - its name is not really
important.

The format of the command could be:
  addinfo <type><id><part><length><message> ...
Basically, this command would allow the server to send one or several
messages, each of them containing:
- <type> is one of: skill, spell, monster, object (artifact), god,
  quest or formula (the latter could be more than one type:
  alchemy_formula, smithery_formula, etc.)
- <id> identifies the skill, spell, monster...
- <part> is for the messages that can be split in several parts.  For
  example, the information about monsters can be divided in: the image
  of the monster, a list of abilities, a longer description and some
  hints about how to deal with them.  See below for details.

I am not sure if <type><id><part> should be sent as 3 numbers, as a
string or as a mix of both.  Numbers are probably easier to handle
(e.g., 8 bits for <type>, 16 bits for <id> and 8 bits for <part>) but
strings could be easier to map to URLs or file names, which can be
useful if the "player book" should be available in HTML format.  One
option would be to send <type> and <part> as numbers (to save space
and ensure uniqueness) and send <id> as a string.

In the following paragraphs, I will use a string representation that
could be suitable for URLs: <type>/<id>#<part>.  This is only for
clarity - this does not imply that a string representation is better
than using numbers.  For example, the S->C protocol could send numbers
that are then converted to strings (URLs) on the client side.

Monsters
--------
* monsters/intro      - general info about monsters (this may be split
                        in several parts: intro#1, intro#2, ...)
* monsters/<id>#name  - full name of the monster or generator
* monsters/<id>#img   - image of the monster (face #)
* monsters/<id>#abil  - like the current description of abilities
* monsters/<id>#gen   - optional reference to generated monster (id)
* monsters/<id>#desc  - extended description and hints about how to
                        deal with that monster

The <id> could be the name of the archetype (which may be different
from the name of the monster) or some unique number.

The client will automatically generate a table giving a list of all
monsters (in HTML format, this could be the index page).  As the
information is sent in parts depending on the contents of random
books, it could be possible that a monster is only known by its image
and abilities while another one has a name and description but no
image yet.

Artifacts
---------
* objects/intro       - general information about weapons, armour,
                        rings, talismans and other objects (this may
                        be split in objects#weapons, ...)
* objects/<id>#name   - full name of that object
* objects/<id>#img    - image of that object (face #)
* objects/<id>#abil   - abilities, like the current description of the
                        properties of the artifacts
* objects/<id>#desc   - hints about how to use that object or maybe a
                        long description of the object (for those that
                        have one) if all hints are already in "intro"

Like for the monsters, the <id> could be the name of the artifact
(archetype + title) or some unique number.  The client will also
automatically generate a table including all known objects.

Alchemy
-------
* formula/<id>        - formula and description

The <id> could be name of the result, although this is not always
unique (some objects can be created in more than one way).  The
uniqueness could be ensured by appending a number to the name of the
objects that are the target of more than one formula.  The <id> could
also be some number based on a hash of the ingredients.

If the result of the formula or its ingredients match some artifacts,
a cross-reference to the corresponsing object/<id> could be added.

In order to make sorting easier for the player, it may be better to
replace the single type "formula" by several types depending on the
skill required: formula_alchemy/<id>, formula_jeweler/<id>, ...

Spells, spellpaths and skills
-----------------------------
* spells/<id>#name    - full name of that spell or prayer
* spells/<id>#img     - image of the spell effect (face #)
* spells/<id>#level   - level and skill required for that spell
* spells/<id>#desc    - hints about how to use that spell
* paths/<path_id>     - list of spells belonging to path <path_id>
* skills/<skill_id>   - description and hints for skill <skill_id>

The client will automatically generate a table including all known
spells.  In addition, it will generate a cross-referenced list for
each path.  Note that it may be possible for a path to refer to a
spell for which no information is known.  Maybe the name of the spell
should always be sent in this case?

When a player reads a spell book or prayer book, the name of the spell
and the corresponsing skill and level are automatically sent, even if
the player fails to learn the spell (this information is already sent
today in a normal message).  Spells that are not known by the player
would be mentioned in the "player book" with a sentence like "You do
not know that spell".  Spells that are known but that the player is
unable to cast (insufficient level or denied path) would be mentioned
with a sentence like "You know that spell but are unable to cast it."

I am not sure if it would be interesting (wrt. gameplay) to have to
find the hints or the detailled description of the spell in random
books.  It may be better to always include this information in the
spellbooks (as this is currently done via the "addspell" command).  In
that case, it would not make much sense to split the spell description
in several parts (#name, #img, #level, #desc) if they are always sent
together.  The same applies for the skill scrolls: the description of
the skill could be sent to the client when the skill is acquired
instead of having to be found in a random book (except for skills that
cannot be found in scrolls, such as the writing skill).

Currently, the "addspell" command includes path information.  This is
used for highlighting some spells (attuned/repelled/denied) when the
client displays the list of spells to the player.  With this proposal,
this would no longer be the case and the player would have to find and
read some books about spellpaths in order to get the automatic
highlighting in the list.

Gods and religions
------------------
* gods/<id>#img        - image of the avatar (face #)
* gods/<id>#ennemy     - name of the ennemy god
* gods/<id>#ennemy_race- name of the ennemy race
* gods/<id>#align_race - name of the aligned race
* gods/<id>#aura       - protections and vulnerabilities
* gods/<id>#paths      - attuned/repelled/denied paths
* gods/<id>#blessing   - effects of blessing/curse
* gods/<id>#possession - effects of holy possession

Quests and other random messages
--------------------------------
* info/<id>            - description of a quest or other useful stuff

Some random messages contain hints about where to find a quest or
general information about the game or the crossfire world.  The <id>
could be just a sequence number but it could also be a name if each
of these messages is given a unique name.

Some of these messages could also be sent to the client immediately
after creating a new character: they would replace the information
that is currently given in the HallOfSelection and the general game
hints that are given in the initial mission and in the central square
of Scorn.  This would ensure that all new characters start with a few
pages of information about crossfire, how to play the game, and what
are the main features of the race and class that have been selected.
All characters starting with some spells and skills would also be
given the corresponding information (see spells and skills above).

Changes to the archetypes and maps
----------------------------------
In order to provide the information described above, some changes to
the archetypes and maps will be necessary: all books and other
readable items would have to be reorganized.  It may be better to
have a clear difference between the books that will be "consumed" by
the player (spell books and other random books and scrolls) and the
ones that are part of some maps and should not be grabbed by the
player.

New descriptions would be needed for some monsters, for the skills
and for all "info" messages that should replace the current player
handbook.  These would probably require new files in the lib
directory.  I am not sure about where to store the extended
description and the hints for dealing with specific monsters.  The
"msg" field of the archetypes is already used by some monsters so it
cannot be used for this purpose.

Libraries are a bit special because the new concept of grabbing
pages from random books and putting them into one's own book would
not work well with libraries (this could upset the librarian and
other readers).  One workaround would be that if a readable object
has "no_pick 1", then the player would get the message "You copy the
information about <whatever> into your book" instead of getting the
message "You take the information about <whatever> and add it to
your book".  In that case, it would not be necessary to modify the
libraries and other maps using books that cannot be picked up.  This
could even be applied to spell books: a map could have a "no_pick"
spell book or prayer book so that the book stays there even after
being read.  This could be useful to ensure that quest spells that
are difficult to get at cannot be taken out of a deep dungeon and
given to a low-level player.

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)?
- 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?
- 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).
- 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?
- If these special books are in-game objects, how to prevent players
  from exchanging these books, destroying them or losing them?  They
  could be permanently locked with no way to unlock them but that does
  not feel right.  Marking them as godgiven items would cause a great
  loss to the players who unlock and drop the wrong items by accident.
- Should there be just one "player book" per player (divided into
  chapters for spells, monsters, etc.) or should there be one book of
  each type?
- 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 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?
- 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?
- 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?

Conclusion
----------
I think that such a system could improve the world of crossfire
because the important information would be given by the game itself
instead of being found in some external document (spoiler, handbook).
It would also reduce the artificial difference that exists between the
behavior of spell books and other types of books: some of them vanish
after use, some others don't.

However, implementing all this will require a lot of work.  I will not
have the time to do that in the near future (next 6 months or so) and
I am not even sure that I will have the time to discuss this proposal.
For the moment, I prefer to spend the bits of spare time that I find
on other things such as creating more alchemy quest maps and finishing
my map checking script.  So please consider this proposal as a brain
dump without any promise that it will ever be implemented.  If you
like these ideas and would like to implement them, feel free to try...

-Raphael