[Adonthell-devel] quest logs

[Kai Sterker]

Something new: if the plot gets more complex, with plenty of quests and 
dialogues, it's essential to have some kind of diary, that helps 
players recall details of events a while ago. So I sat down and wrote 
the basic system.

It involves 4 classes: log_manager, log_book, log_entry and 
log_keywords.

log_manager is a static class that can manage various log_books. It's 
up to an actual game, how many different log books are used. You could 
have one for open quests, for completed quests, for dialogues, a 
generic diary, etc ... .

The log_manager allows to add new log entries into the books. It allows 
to register a callback that is executed whenever a new entry is made. 
That allows for example the gui to notify players that an entry has 
been made.


Each log_book contains a list of topics and for each topic a list of 
log_entries. For each topic, it knows whether there have been made new 
entries since that topic has been last retrieved.

Retrieval is possible by topic, date or unique id. Latter serves a 
number of purposes:

* cross-references between entries. Of course that would require the 
ability
  of the gui to display hyperlinks. (More on that below).
* a bookmark feature. The gui could remember which entry was displayed 
last and
  automatically redisplay that on opening.
* keyword feature. The keyword class keeps track of all entries 
containing
  certain (predefined) keywords (More on that later).


Each log_entry consists of a timestamp, a text and topic. The timestamp 
is created automatically, text and topic have to be specified, as well 
as the id for the entry. Together with book and topic, this will form 
the uid discussed above.


The log_keyword class can be used to create an automatic index or a 
search function. Usually, it will get a list of keywords at the 
beginning of the game. Whenever a new entry is created, it will scan 
the text for the keywords it knows and remember the entry. The index 
could then display all keywords that have entries assigned to them and 
present them to the player.

A search function would add a new keyword at runtime and re-index all 
entries that have been made so far. I personally wouldn't implement 
that for our game, though, as it totally breaks the book analogy. An 
index OTOH might be very helpful to find information that is spread 
across different entries of different books. For example, everything 
that concerns a certain character, place or item.



Something about the text of log_entries: instead of using plain text, I 
suggest to use something more powerful. A subset of xhtml for example 
(since we already depend on libxml, why not make use of that). Our text 
widget would then need to decode the text and format it accordingly. 
That would not only be useful for the log_books, but also for other 
texts like item descriptions and even dialogues (For example, different 
colors could be achieved by applying appropriate tags before handing 
the text to the widget). I guess that many formats (like colored or 
bold text) can be passed on to freetype, so that the text widget 
doesn't have to do much. However, there should also be a possibility to 
reference images that will be included at that position. No fancy 
textwrapping is required. A centered image with no text left and right 
should do.



Another issue is creating log entries from dialogues. Obviously, simply 
recording the whole dialogue isn't an option. For one, few people would 
want to scan a lengthy conversation for relevant information. Second, 
people will usually speak several times to the same NPC, resulting in 
duplicate entries.
And finally, it isn't at all flexible.

Most flexibility would be given by using the Python log API to add 
entries at specified points of the dialogue, but that's not very 
comfortable. Not to mention that our writers might not want to enter 
the depths of programming.

Here are a few thoughts I have on that topic:
* As a log entry usually summarizes a larger portion of a dialogue, it 
should
  not be entered at node level.
* The entry should be able to differ, depending on how the dialogue 
progressed.
* The same information must not be logged more than once.

With that in mind, here's my suggestion:
A dialogue can contain a number of log entries, each with its own topic 
and id. However, the text does not need to be a single block, but can 
consist of multiple parts. Each part in turn can be assigned to one (or 
more) nodes. When one such node is selected, the matching part is added 
to the log text. At the end of the dialogue, the assembled text is 
inserted into the log book. However, this will only work the first 
time. Afterwards, an entry with this id does already exist and will not 
be replaced. To prevent irrelevant (or incomplete information) from 
being added, parts can be marked as required. If not all required parts 
are in the text when the dialogue ends, nothing will be added.

As most log entries will be created from within dialogues, I think its 
worth to allow some flexibility. Other entries might be created from 
within scripts, whenever something special happens that needs be 
recorded. Finally, we might allow players to record their own notes.


Hope you like this stuff. Suggestions and improvements welcome, of 
course.

Kai