[Adonthell-devel] modular dialogues

[Kai Sterker]

The more I think about the way we want to organize our plot, the more
concerned I am about the current dialogues we have. If the player will
be able to behave in different ways, NPCs he deals with will also have
to behave according to the player. Right now that means they would get
really extensive dialogues.

And if you look at Erek's or Orloth's dialogue (Lucia is a good - or
rather bad - example too), you'll see how messed up they get. And they
are not reusable at all! 

The only sensible solution seems to make the dialogues more modular. I
had some thoughts about that (see the dev diary), but there are a few
more things that came to my mind. So before I forget them, I thought I
better write them down. That'll also give you a chance to comment on
this. As always, improvements, criticism and the like is welcome.


I'm not exactly sure how dialogues should be split into modules. There
are multiple possibilities that all require the same additions to
dlgedit. Basically, we could limit a module to a single topic. This
could be tailored to a single NPC, but also reusable by others. A
dialogue would then be made of several modules with a few additional
nodes to connect the modules. That's just one way to do it; there might
be better alternatives. Anyway, I mainly want to cover issues concerning
dlgedit here (that's why I'm posting to the devel ML).

Basically, a module would be represented by a single node 'icon'. But
unlike the nodes we have now, you could 'descent' into it to view (and
edit) it's contents. (Which can be single nodes and other modules). It's
very much the same concept as with files and directories. A file
corresponds to a single dialogue node (i.e. a line of text), while a
directory corresponds to a dialogue module (i.e. a collection of nodes
and modules). As a direct consequence, each dialogue is also a module
(and could be used by a yet higher level dialogue).

To make the navigation through a dialogue's modules easier, dlgedit
would also get a module-tree. That is a tree structure with the current
dialogue as root, and all the modules it uses as nodes of the tree. If a
module uses other modules internally, this will be directly visible from
the tree. Again, this concept is exactly the same as in many file
browsers.


That are the basics, now it'll get more interesting (and technical).
Dialogues that include a module only use references to it. They don't
copy it's contents. That means, any changes made to the module will
immediately appear in all dialogues using the module. I'm not sure if
this is possible, but I hope that this is not only true for the dialogue
sources, but also for the actual dialogue scripts. That means, it
shouldn't be necessary to recompile all dialogues just because a module
they use has been changed.

Already scared (or amazed)? Just wait, it'll get even better. Imagine we
have a module that nearly fits into our dialogue, but not quite.
Wouldn't it be cool to edit it in place, without changing the actual
module (and thus all the dialogues that use it). I think it is possible
to allow that. One could modify a few lines or text, add or delete a few
nodes, or even include a few other modules.

For that to work, each node needs a unique (and fixed) id. That could be
composed of the module filename and a serial number. I.e. the first node
of a dialogue/module gets id 0, the second id 1, and so on. If nodes are
deleted, the gaps will remain.
Now if I change the node of an included module (A), dlgedit does exactly
know which node has been edited and keep track of it in the current
dialogue (B). Each time the dialogue is loaded, it would first load the
module and afterwards apply all the changes it has recorded for that
module.
The cool thing is, another, even bigger dialogue (C) that includes
dialogue B can make further changes to module A, that are restricted to
dialogue C, but neither affect B nor A!

The id is further required to allow links from the higher level dialogue
to any node of included modules. Even direct links between two included
modules should be possible that way.


The loading process of a dialogue (in the editor) is then the following:
First of all, all simple nodes, then all modules in the order of their
inclusion. Next all local changes to the modules. Modified nodes, new
and deleted nodes. And finally all the links.


Of course, all that would require a rewrite of the way links between the
nodes are handled now. Even links between simple nodes of a dialogue
should make use of their id, for consistency.


At first, we might 'flatten' a dialogue on compilation, i.e. create one
python script with all the text and code of the modules used by that
dialogue. That way we need not change the dialogue engine. But it would
be definately cool if the engine could assemble the final dialogue from
the individual modules and local changes too. That's certainly the
ultimate goal.


That are all my thoughts for now. I'll have to sleep a few nights over
the stuff, but it might be the next thing I'll concentrate on. Sounds
useful to me, and very interesting as well :). What do you guys think?

Kai