I suppose that few people are writing rpg games at the moment. What would you think about defining common format for representing dialogs (as in 'talk', not as in 'window') ? This would cover only basic things - nodes, options, with generic tags for preconditions/side effects and display. Everything game-dependent would be just a CDATA, passed to application to interpret.
What is the benefit of creating such format, if it leaves most 'important' things undefined ? To allow various tools to work on it, regardless of game details. Such tools could allow to enter 'display' tag contents, without worrying if it is in fact html code, plain text, link to image or anything. It could display graph of dialog transitions without worrying what is really happening inside.
It would be also possible to write almost generic interpreter for such dialogs, with few well defined entry points/callbacks - almost generic, meaning it would have to stick to certain scripting language (for example to interpret precondition checks).
<option id="0" auto="false" forward="1">
- id of first node to display when dialog is started. Please note that this does not mean that same thing will be displayed each time - there is a chance to forward control with auto attribute in option tag. Required.node.id
- identifier of node, has to be unique in entire dialog, doesn't have to be numeric. Required.node/exec
- code which will be executed when entering given node. Can be used for marking that you have already seen some option/learned given thing/to give item to player/run shop dialog/etc. Not required.node/display
- text to be displayed to user when he enters this node. Format etc dependent on game engine - this is why it is inside CDATA, to allow even another independent xml markup inside, or anything else what is needed. Not required (for 'silent', transition nodes)node/option
- one of options to display to user when he is at given node. There should be at least one option per node. option.id
- id of option. Has to be unique inside given node, but can repeat between various nodes. Required.option.auto
- if true and precondition for this node is fulfilled, dialog goes to 'forward' node without waiting for user interaction. It can be used for example for dispatch nodes at start, or for some side informations which could forward back to main conversation node automatically. If more that one option will have auto set to true and precondition fulfilled, first option will be chosen (or maybe random one?). Defaults to false.option.forward
- pointer to node to which dialog should go if this option is chosen. Has to point to one of existing options in given dialog. Probably there is a need for reserved 'exit' forward here to end dialog - or maybe exit can be done by special node ? Maybe both ? Required.option/precondition
- piece of code which will be evaluated by game engine to see if given option should be displayed. Could check charisma/intelligence of player, quest solution, being already to different node etc. Defaults to always fulfilled.option/display
- text to display as an option choice. Required.option/exec
- piece of code to be execute after player had chosen given option, but before forwarding to next node. Could be used to set quest status, players variables etc. Giving items/etc is probably better done in separate nodes with single ack option.
Many dialogs would probably start with 'silent' node with number of auto options to forward to correct greeting depending on player knowledge/status/feelings of mob versus player.
Some game engines could for example require some special node 'break' which would run if player break conversation forcibly (disconnect, pressing escape, etc) - dialog would then execute it regardless of where it was before.
As you see, it is almost totally game agnostic. It would be possible to write a tool which would draw a mem-map like graph of all nodes/transitions, annotating them with ids of nodes/options without any knowledge of game details.
What do you think ? Any ideas about what's wrong with format ? I would like it to be as generic as possible, with not too many detailed behaviours, to avoid burden for game engine.