[Adonthell-devel] Dlgedit: Idea for modular dialogues design

[Kai Sterker]

In case I forget:

Before this whole worldtest stuff, I had planned to compile dlgedit on
Windows, so that Andrew (and possibly others) could use it. Shouldn't
be too difficult compared to compiling the engine itself. However,
that also reminded me that there are two unfinished parts in the
recent version (see
http://adonthell.berlios.de/doc/index.php/Tasks:Dlgedit).

The first item requires an update to the part that generates the final
python script, so it will play nicely with the changed character and
quest implementation. It's no big deal, but it involves parsing and
replacing parts of strings, something that's awkward at best with C++.
Which is the main reason why this is still open ;-).

The other task (being able to modularize dialogues) is mostly open
because of design issues. And that is where I had an inspiration this
week which I wanted to share.

There are two design issues still open. One is regarding the dialogue
compiler: should the resulting python scripts be modular as well, or
is it okay to compile everything into one script? The downside of
latter is that changes to a dialogue module will result in having to
recompile all dialogues that use it. But I'd be willing to go with
that for the beginning, since at best it doesn't require any change to
the compiler at all.

The other issue (and I am sorry that it took me so long to get to the
point) is the user interface aspect of modular dialogues, i.e. how the
connections between the different levels of a dialogue will work.
Right now, each dialogue module appears as a simple box to the outside
world. There is no obvious way to make a connection between an outside
node and a node inside the module. You would have to select the source
node, drill down into the module and select the target node to
complete the connection. That would require some changes to the
internal data model of the editor, as we'd have two different
connections: the visible one between a node and the module box and an
invisible one between the two actual nodes.

If, however, we would harvest all start- and end nodes from the module
(i.e. nodes with no predecessor and nodes with no followers) and
display them around the module box, connections could be made directly
to those nodes (and only those). That would simplify both the GUI
design and the internal data model with one drawback: one could not
make connections to arbitrary nodes inside the module. While this
sounds like a restriction in theory, I believe that in reality it
won't make a big difference. Moreover, you'll get modules whose
interface is clearly visible once they are added to a dialogue
(provided start and end nodes can be distinguished).

Um ... not sure if all that makes a terrible lot of sense to anyone,
but feel free to comment. I should perhaps add some sketches to
illustrate what I mean and how it would work ...

Kai