Proposal: Dialog System Implementation

[Bretzel13]

Here's my idea for the language. This should cover a lot of TrainedCircusIdiot's  points

Code:

# Define characters. Kind of like C++ where you declare their class
NPC Guard

SECTION MainDialog # A section of dialog. If you had a lot of dialog, you could organize it into sections and then call them.

SAY Guard "You cannot pass." # SAY [who says it] [what to say]

OPTION leaveOrFight # OPTION [option_name]
1 "Fine." # [option_number] [what_section_to_run]
2 "I must pass."
ENDOPTION # End the option

ENDSECTION


SECTION leaveGuard
   guardDead = False
   PLAYSOUND "testsound.wav" 1 # PLAYSOUND [sound_file] [number_of_times]
   ENDSCRIPT # End the script
ENDSECTION

SECTION attackGuard
   SAY Guard "I will not let you pass."
   ATTACK PC Guard # ATTACK [attacker] [victim]
   # Assumes that PC did not die because game will end and script will not continue
   guardDead = True
   PLAYSOUND "testsound2.wav" 2
ENDSECTION


CALLSECTION MainDialog # CALLSECTION [section_name]

RETURN guardDead # End the script and return whether or not the guard is dead

[shevegen]

Reminds me of the language in Zak Mc Kracken  http://en.wikipedia.org/wiki/Zak_McKracken

A few questions:

- Need the instructions be UPCASED or can they be downcased as well?
- How are the NPCs identified? This example here:

SAY Guard "You cannot pass." # SAY [who says it] [what to say]

To which guard will it refer (i am curious)? Also, I think it would be better
if this syntax would be used:

NPC SAY "lalala"
Reminds me more of a novel:
The renegade says: "Let's leave."
vs
says the renegade: "Let's leave."

Anyway, much better than any XML

[Kaydeth]

I'm confused about the OPTION part

Is this missing something?

OPTION leaveOrFight # OPTION [option_name]
1 "Fine." # [option_number] [what_section_to_run]
2 "I must pass."
ENDOPTION # End the option

Shouldn't it be

OPTION leaveOrFight # OPTION [option_name]
1 "Fine." leaveGuard
2 "I must pass." attackGuard
ENDOPTION # End the option

[mvBarracuda]

I don't want to add more confusion at this point, but the Adonthell dialogue engine / editor might be something worth looking into as well to get inspired:
http://adonthell.berlios.de/doc/index.php/Tools:Dlgedit:Contents

[shevegen]

Interesting - do they use a graphical editor all the way? Or is there any kind of text involved?

http://adonthell.berlios.de/doc/index.php/Tools:Dlgedit:Tutorial

It seems they use pure python actually, which I believe is suboptimal for a dialogue based system

"The dialogue engine allows to embed a function call into a line of text and will insert whatever string this function returns in place of the function. This only works for methods defined in the custom function window (Dialogue → Functions or Ctrl+F). It mustn’t take any arguments and should return a string. For example, the method

 def f_hello (self):
     return "Hello world!" "

And variables need be set like this?

  self.special_info_gained = 1

I think I prefer the version proposed here rather than such a python-based dialogue system, but of course this is just my personal preference.

[Bretzel13]

- Need the instructions be UPCASED or can they be downcased as well?

Doesn't really matter to me, except UPPERCASE does seem to pop it out. But then again, I'll be putting syntax highlighting into the editor so I guess either would work

- How are the NPCs identified? This example here:

SAY Guard "You cannot pass." # SAY [who says it] [what to say]

To which guard will it refer (i am curious)?

Well, I just defined a NPC called Guard as a generic thing. You could just have easily have said NPC Joe, and say SAY Joe "whatever"

Also, I think it would be better if this syntax would be used:

NPC SAY "lalala"
Reminds me more of a novel:
The renegade says: "Let's leave."
vs
says the renegade: "Let's leave."

That's true

[Bretzel13]

I'm confused option the OPTION part

Is this missing something?

OPTION leaveOrFight # OPTION [option_name]
1 "Fine." # [option_number] [what_section_to_run]
2 "I must pass."
ENDOPTION # End the option

Shouldn't it be

OPTION leaveOrFight # OPTION [option_name]
1 "Fine." leaveGuard
2 "I must pass." attackGuard
ENDOPTION # End the option

You're right I just forgot to add that once I changed the way the options worked

[MaximB]

Hello people !

I am not a developer of PARPG but I do want to support mvBarracuda on his idea of using Dlgedit.
I've compiled the Adonthell game engine (0.4) and the tools from source to get it to work - and what can I say , it's remarkable !

The only downfall of it is that dlgedit is currently bound to the Adonthell engine and doesn't support spelling correction, but as I've spoken with the developers it's very possible to separate it from the game engine and use it with any other game engine, moreover it's free source (GPLv2 or later) which suites your game.
Why reinvent the wheel if you already got a free working tool you can use ?

About dlgedit :

After compiling and running it, you don't need to be a programmer to use it with the basic functions as making dialog trees.
I use it for my own little project and it works great.
You also got more advances features like adding "functions scripts" to each dialog and other more advanced stuff.
Once a tree has been made you can export it as a python script and edit it by hand/vim/edit...
There are also other scripts which helps with exporting the dialog and use it with your engine.

They have a small tutorial to show you the very basic usage :
http://adonthell.berlios.de/doc/index.php/Tools:Dlgedit:Tutorial

Here is a script they made to "execute the data" : http://github.com/ksterker/adonthell/blob/6fc0be3bcfc06ed7cd3695094d52c015f941e310/test/data/dialogues/dialogue.py

Here's another one for C++ : http://github.com/ksterker/adonthell/blob/6fc0be3bcfc06ed7cd3695094d52c015f941e310/src/rpg/dialog.cc

Here's some other scripts for use it with your own engine :
http://github.com/ksterker/adonthell/blob/6fc0be3bcfc06ed7cd3695094d52c015f941e310/src/rpg/dialog.cc

http://github.com/ksterker/adonthell/blob/6fc0be3bcfc06ed7cd3695094d52c015f941e310/test/dialogtest.py

Moreover the guys at their IRC channel ( Adonthell @ freenodes ) are extremely helpful.

 

[shevegen]

I think one problem i have with it is that it is a valid python script right?

I believe a specific tailor-made dialog language (a domain specific language if you will) would be better than pure python scripts.

The graphical stuff is cool though, and if possible should exist in parpg too, but I am not so enthusiastic about the created .py
scripts. A specific, very simple dialog based message should be nicer.

I mean, I am not trying to push that discussion here in any direction (to the one I prefer more) - we could try both approaches and see which one will be nicer in the long run anyway, or? Like switching from one to the other easily lateron.

Some kind of graphical editor - or integrated with a world editor - would be cool at any rate though. A bit like a toolkit for creating worlds and games.

[MaximB]

Well, as I've said I am not a programmer but from a writers point of view you currently suggesting in the PARPG wiki to use Dia for dialog trees, which was the first tool I've tried for my dialogs - and it's very unconformable for long dialog trees.
And Dia is just for visual view of the tree, it cannot be used in the actual game ... all the dialogs then needs to be rewritten from scratch with some other program or language.

You see it from the programmers view which I can get, but from the writers point of view you have to find something easy that you could then integrate into the game.
     

[Kaydeth]

I agree with Shevegan. The fact that dlgedit generates python code is a bit of a turn off. For one, not everyone likes to work with a gui editor so having a scripting language gives them the option of just writing dialogues in an editor.

We may want to borrow the gui component but I don't think we are there yet.

Bretzel, can I assume you are moving forward with the syntax you layed out? If so do you think you can update the Wiki proposal (http://wiki.parpg.net/Proposals:Dialog_Implementation)?

You could also create a new proposal if you wish. But we definitely need to document the dialog syntax somewhere.

[superfluid]

I think Tech-demo 1 will be easy to reach (i should never say that before its finished eh? but hey I am gonna stand by that comment now)

My complaint against XML basically boils down that it is too verbose. It is not the simplest approach that works elegantly.

All the closing tags are - for me - redundant information:

<name> joe </name>

YAML usually uses that instead:
name: joe

which is better (well ok you must make a newline afterwards, but I am fine with that because I can read it easier)
Unfortunately yaml has a few other problems, such as that parsing errors are a bit harder to track than in XML

Personally I think it would be nice if we can come up with a syntax that is easy to read and allows for the needed complexity too. I just hope it wond end up like Wesnoth WML. Look here for the problems it has:

http://www.wesnoth.org/wiki/AnimationWML

Scroll down to the examples "Example Syntax " and look at [if] tags
I am sorry but if XML starts to become a real programming language where one needs to put conditionals like [if] into tags, then in my opinion something is very wrong with the design. Also note all the closing tags for the redundant information. I think it can be done easier and better without XML-like syntax.

I'd like to throw my opinion in on this if I may... As much as I'm loathe to use XML, writing our own lexer/parser is almost certaintly a worse idea and seems like it would lead to  a lot of yak shaving, whereas our efforts could be better focused using an off the shelf library and writing the component that would interpret an abstract tree and do something useful with it... if that makes any sense.

Its funny, but when I started reading this thead I immediately though of YAML. I've had some experience using YAML as a domain specific language for software automation, and its actually quite a nice fit. It's very readable, even for non-technical folks, it's not as as heavy as XML and has just as good support library-wise as XML. Check out this example, I don't think it's too far from what we want to do:


    ---
    NAME:    Administrator changes their timezone
    ID:      admin_changes_tz
    SUMMARY: Administrators need to have a mechanism for changing their
             timezone.
    PRECONDITIONS:
        - ensure user exists: admin
        - ensure timezone is: America/Vancouver
    INSTRUCTIONS:
        - login:
            username: admin
            password: testpass
        - goto page: Account Settings
        - verify current timezone is: America/Vancouver
        - change timezone to: Australia/Brisbane
        - verify current timezone is: Australia/Brisbane
    POSTCONDITIONS:
        - ensure timezone is: America/Vancouver


http://search.cpan.org/dist/Test-A8N/lib/Test/A8N.pm

[zenbitz]

YAML or JSON (subclass of YAML) would probably work.  Not sure which is better for dialogue.  I am not sure it handles flow control though.

I would just do it in Python... I mean, the stupid interpreter is already built in!   

For an example of an app like this (non game related): http://www.pymol.org

[superfluid]

YAML or JSON (subclass of YAML) would probably work.  Not sure which is better for dialogue.  I am not sure it handles flow control though.

I would just do it in Python... I mean, the stupid interpreter is already built in!   

For an example of an app like this (non game related): http://www.pymol.org

I like JSON, but my one reservation about it is that it's stricter about proper quoting of keys and stuff like that... it's more data structure-y

[Kaydeth]

I believe Bretzel is moving forward with his home grown syntax but I don't know how far he's gotten and I haven't seen him around lately.

Can you can give an example of YAML script or which ever language you think is best? perhaps translate Bretzel's example? It's hard to come to any conclusion without something to look at.  Also do you know how the python library will translate the script? What will it return to the caller? One of the advantages of writing your own parser is that you control exactly how the data is put together when the script is read.