Common xml dialog format for RPGs ?

Shared Code
#1

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).

Format proposal:


<dialog entry="0">
      <node id="0">
            <exec>[CDATA[            ]]</exec>
            <display>[CDATA[            ]]</display>
            
            <option id="0" auto="false" forward="1">
                  <precondition>[CDATA[                  ]]</precondition>
                  <display>[CDATA[                  ]]</display>
                  <exec>[CDATA[                  ]]</exec>      
            </option>
      </node>
</dialog>

Explanation:

dialog.entry - 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.

#2

OTTOMH, why are you thinking scripting language for pre conditions and exec. Why not make them class names that implement IPrecondition and IExec interfaces, with an optional “scriptname” part. It is then up to the application to decide how to process these. If you added an implementation, say JythonPreCondition, it would execute the jython script given in scriptname, to work out what to do.

(Apologies for the c++isms in the interface names, but it makes the idea clearer)

edit: must learn how to spell.

#3

[quote]OTTOMH, why are you thinking scripting language for pre conditions and exec. Why not make them class names that implement IPrecondition and IExec interfaces, with an optional “scriptname” part.
[/quote]
With non-trivial dialog, you could easily end up with hundreds of options, implementing things like [player.charisma>16]. In application you could have hundreds of dialogs, giving you tens of thousand few-line classes.
Another, same important reason, is to have check/exec code in the same place as rest of dialog. This way, you keep same things in same place - you don’t need to reference outside java files to discover what is really happening.

And most important - there is nothing which will stop you from using it this way. If you want, you can write com.mygame.CharismaGreaterThan16Check in precondition check. I personally prefer to use inlined scripting language for two reasons given above, but format does not require it.

#4

This is how my RPG game/maker is implementing this at the moment. This format was suggested by Kevin Glass (MAn he’s smart):


<?xml version="1.0" encoding="UTF-8"?>

<!--
    Document   : dialogs.xml
    Created on : July 21, 2003, 7:37 AM
    Author     : Krypto
    Description:
        Purpose of the document follows.
-->
<Conversation NPC="baldie">
<Statement id="0">
  <Text>Hail Adventurer, what can I do for you today?</Text>
  <Reply Text="I need money!">
    <GotoStatement target="1"/>
  </Reply>
  <Reply Text="I need food!">
    <GotoStatement target="2"/>
  </Reply>
  <Reply Text="Nothing thanks!">
    <GotoStatement target="3"/>
  </Reply>
</Statement>
<Statement id="1">
<Text>Hey, I think you're in the wrong place, you might want to try the bank!</Text>
  <Reply Text="Ah, Ok!">
    <GotoStatement target="0"/>
  </Reply>
</Statement>
<Statement id="2">
  <Text>Would you like to buy some bread? Only 1 gold piece!</Text>
  <Reply Text="Yes please">
    <GiveObject>
    <Item type="Money" name="gold" amount="1" image="items/money/goldbag.png"/>
    </GiveObject>
    <GetObject>
     <Item type="Powerup" name="bread" amount="10" image="items/powerups/bread.png"/>
    </GetObject>
    <GotoStatement target="0"/>
  </Reply>
  <Reply Text="No thanks.">
    <GotoStatement target="0"/>
  </Reply>
</Statement> 
<Statement id="3">
  <Text>Farewell then, do feel free to drop bye again!</Text>
  <Reply Text="Farewell">
    <EndConvo/>
    <GotoStatement target="0"/>
  </Reply>
</Statement>
</Conversation>

I have a factory of sorts that takes a node and gives pack the proper “parser/java class” to deal with whats going on.

#5

I like the idea generally. I think precoditions and exec need to be optional but I guess this is what you meant anyway.

Its essentailly a generic version of what I suggested to Krypto all them months ago, which is cool. I might go ahead and use this dialog system in Mini Adventure if you don’t mind?

Kev

#6

Don’t mind ? It is exactly why I was posting it here :slight_smile:

Yes, for exec I have forgotten to add optional. For precondition, it is optional in meaning you don’t have to specify it, but in fact it means it is always fullfilled.

I suppose I will have to start writing editor now…

#7

It works great, and I assumed you already had it implimented. How is you dialog in mini adventure working now. On a side note Kev, I have a thread reguarding my game/Editor design in the Game design thread. I’d love to get your input. I’m thinking of extending my stuff into an RPG maker.

#8

I would be very interested in that and would love to integrate it into my Game Maker/ Engine.
:smiley:

#9

Thats why this is so ideal for me, I’ve not got as far as dialog yet :slight_smile: Moving house kinda got in the way

Kev

#10

To validate the idea, I have written quick-and-dirty converter to java. This is just an example implementation and would have to be done by game - but by using utility classes I have written, target-specific generation code is only two pages of code (ugly, but straighforward). In this particular example I have decided that dialog object is initialized with DialogEnvironment interface, which is a way to access data inside game pluse display text/options. Two main methods would be display(String nodeText) and displayOption(String nodeId, String optionId, String optionText). UI code in game then would allow player to select particular option and call dialog.choice(nodeId, optionId).

Once again - this is just an example, because it was easiest to validate the idea on java code. It is perfectly possible to convert xml to script language, or even interpret it on runtime directly from xml.

I have used a bit modified example from Kev:


Too long and unreadable...

And here is generated java code (after whitespace reformatting)


Too long and unreadable...

Edit: These listings really do not look good here. You can see them at http://nwn-j3d.sourceforge.net/misc/dialogtest.pdf

In real case, test1 class would probably extend base class or implement some interface with methods dialogEntry and setDialogEnvironment, so it could be used dynamically.

I’m probably going to use groovy for actual implementation, but there will be nothing in editor/parser code which would require it in game.

#11

You can play with proof-of-concept editor at
http://nwn-j3d.sourceforge.net/misc/dialogeditor.jnlp

If you want to see our test example which was discussed above, it is available at http://nwn-j3d.sourceforge.net/misc/test1.xml

This is just a test app, only basic stuff implemented. Only fancy feature is support for copy/paste/drag/drop inside dialog tree and to/from native apps (or just different dialog windows).

To turn it into usable application, there is a lot of work left:

  • hierarchical dialog preview (maybe graph using JGraph?)
  • ability to rename links pointing to current node
  • global validation check (if all forward links points to valid nodes, if all nodes are connected, if there is no display for options with auto, etc)
  • ability to plug in exporter modules
  • ability to plug in display modules (or at least allow html)
  • better gui for node editing
  • make everything configurable/persistent
    and a lot more.

If you will change id/display of node/option, there is a big chance you will have to press F5 to refresh view - default JTree implementation caches a bit too much and leave labels too short to display everything. Please also be forgiving to undo/redo - it sometimes records same edit twice.

My questions:
Will you use it when it is finished?
What key features are missing ?
Do you think it makes sense to create a dev.java.net or sf.net project for it (possibly writing import/export routines for some already existing games) ?

Currently app requires jdk1.5b1.

#12

Should have posted back, Mini Adventure is running on this system, although actions don’t do anything since I haven’t quite figured out what I’m doing there yet.

This failed for me, the auto download of java1.5b didn’t work :(. You got any screenshots I could look at? I’ve got some pretty fixed ideas how I’d like to do it (bespoke gui style, flow chart style) but if its free I’d be willing to consider.

I’d consider using it, but without being able to see it, hard to tell. It’d need to be produced as a component that I embed into my editor suite (please).

Features, don’t know yet…

Most existing games presumably have a prescribed editing system and so I’m not sure it makes sense to create a project for the storing the exporters.

The 1.5 bit is a sticking point for me. I’m expecting to release the client against 1.5 but the toolset itself I was hoping to keep in 1.4.

Kev

#13

I have ported it to 1.4.2
Ugliness factor increased twofold (I have forgotten how ugly 1.4 metal was), I had to hack transferable method in one of core classes (it was not exposed in 1.4), but I think everything should work now.

#14

Had a quick play, works really well, lots of solid feeling bits.

Features:

  1. I’d like to see a graphical represenation of the flow (flow chart style?) of the dialog. I’d find that easier to interpret.

  2. Would be nice to have some way of viewing the conversation “running” as it were. (Obviously can’t generically resolve exec and precon)

  3. To integrate with my suite the panel (and addition dialogs) would need to be “standalone” to plugin.

  4. Would also be cool to be able to plugin components into those exec/precon boxes to support specific implementations of them.

However, loooking cool…

Kev

#15

I was thinking about it. Problem is, that it is next to impossible to arrange it automatically in nice shape. Easiest would be to allow user to arrange node himself and save it on disk together with dialog - but on the other hand, such placement would be very application specific and thus not really fitting inside generic xml format.

As long as we assume that all preconditions are true, it is easy to add.

It is generally trivial to make it embeddable. At what level would you like to keep it ? Internal frames or just their content in form of JPanel ?

There are few points here. First - syntax aware editor (with highlight, possibly even autocompletion for simple language). Second - some kind of content validator if possible (early compile). Then ability to run dialog inside specific environment.

Current xml is available at all times from application, so compilation/run can be just a special case of export.

Biggest problem is probably turning my code into something I will not be ashamed to show - I’m believer in refactor-when-needed, so there is a plenty of public variables everywhere, converted to getters/setters only when needed. In case of embedding, I will have to do it all at start, to avoid breaking interface later…

#16

Embedding the component:

As long as its just a JPanel with a bunch of extra functionality to be able to respond to events on the GUI and extra data should be ok…

I’m not quite sure how much I can use, I’m going to knock something together for my use straight away, but I’ll but looking to move over to the standard in pretty short order.

Let me know how it goes…

Kev

#17

Having rethought my current stage of development I’ve got a chunk of NPC tool to write first (movement, stat defintion) before getting onto convo dialog.

So, if you’ve got something you’d be willing to share in a few days I’d really appreciate it.

Kev

#18

I have done quick dump of sources at
http://nwn-j3d.sourceforge.net/misc/dialogeditor.src.zip

No comments in code at the moment, unfortunately. I will try to add few things today, for sure will not do anything tomorrow and maybe hack few things at Monday.

I have made it pluggable. Please look at org.gjt.abies.dialog.editor, classes Editor and DialogDocument - you would need to write similar functionality if you want to embed dialog editor in your application. Most of it is optional, you just need to implement DialogPanelEnvironment with 3 trivial methods.

To embed editor, you need to create DialogPanel. File parameter can be null, but Dialog needs to be initialized - either by reading with org.gjt.abies.dialog.DialogParser from file, or by few lines of code (like in Editor). DialogPanel mostly work by itself, you can get number of public actions out of it and insert them inside menu/shortcuts/toolbar/etc. At the moment, only magic action inside is delete-selected action, which is mapped to DEL key.

If you will have any doubts how to implement something which is already in standalone app, you can look into DialogDocument and Editor classes (they are quite simple) and into source of actions (Editor,DialogDocument,DialogPanel).

#19

Thanks very much, sounds pretty much ideal for me!

Hopefully, I’ll be adding my new editors tonight and hence be integrating it tomorrow…

Thanks again, let me know how your updates go…

Kev

#20

To avoid spamming board with small messages, I’ll just edit this one with changelog.

10/04/2004 17:50:

  • added dialog preview (available under Export/Test Run) - you can either click or press keys from 1-9 (for more options, you need to use mouse)

12 April 2004 23:30

  • if you press enter after typing non-existing forward in option, program will ask if it should create/edit new node
  • added support classes for problems checker, plus Ctrl-F5 problems preview
  • dialog root node can be now copied/dragged
  • when renaming node if, all linking options can be retargetted
  • put all big textfields into scrollpanes

13 April 2004

  • corrected borders inside scrollpanes in main editor
  • added preliminary hierarchical view
  • added bold to node name display in tree

TODO:

  • after changing node show start of display/exec/precond
  • add graph view
  • pluggable editors/runners
  • allow configuration of display strings for trees
  • remember location of problems pane
  • remember location of MDF/problems pane per document
  • remember maximized property for all frames and do not corrupt size then
  • escape all strings in tooltips for HTML codes
  • document source code